Erklärung zur Barrierefreiheit

1. Geltungsbereich

Diese Erklärung gilt für folgende digitale Angebote der Inklusion Digital GmbH:

• SPLINT (https://splint.schule) — SPLINT Web-App (Informationsseite und eingeloggte Anwendung)
• PDF-Förderpläne und weitere PDF-Exporte, die aus der App heraus erzeugt werden (siehe Abschnitt 3.3)

Nicht erfasst sind:

• unser Selbstlernkurs auf academy.splint.schule (LearnWorlds — verantwortet der Anbieter)
• interne Verwaltungs- und Werkzeug-Bereiche, die für reguläre Endnutzer:innen nicht erreichbar sind

Für die Barrierefreiheit der Drittinhalte sind die jeweiligen Anbieter verantwortlich. Die internen Bereiche werden bei Bedarf separat bewertet.

2. Stand der Barrierefreiheit

Stand: 05. August 2026.

Diese Bewertung beruht auf zwei aufeinander aufbauenden Audits:

1. Externe Prüfung durch das Kompetenzzentrum Barrierefreie IT (KBIT) der IT.NRW vom 11.–22. Oktober 2024. Diese unabhängige Stelle prüfte acht repräsentative Seiten unserer Anwendung (Startseite, Anmeldung, Dashboard, Schüler:innen-Übersicht, Schüler-Ansicht, Förderziel, Förderplan-Erstellung, Fördermaßnahme-Auswahl, Beobachtung-Anfrage und -Bearbeitung) nach dem KBIT-Prüfschema und damit auf Basis von EN 301 549 und WCAG 2.1.
2. Internes statisches Code-Audit vom Mai 2026, das u. a. die zentralen Komponenten-Bibliotheken, das Formular-System, die Token-Kontraste, die Heading-Struktur und das Tabellen-System systematisch durchleuchtet hat.

2.1 — Barrierefreiheits-Widget der Anwendung

In der Anwendung steht ein eigenes Barrierefreiheits-Widget zur Verfügung. Es spiegelt einige Anpassungs-Möglichkeiten wider, die moderne Browser von Haus aus bieten — gebündelt direkt in der Anwendung. Über das Widget können Nutzer:innen unter anderem:

• die Schriftgröße in mehreren Stufen erhöhen
• einen erhöhten Kontrast / Hochkontrast-Modus aktivieren
• den Buchstaben- und Zeilenabstand erhöhen
• den Cursor vergrößern
• eine Lesehilfe / Lese-Linie einblenden

Das Widget ist in jeder Seite der Anwendung über das entsprechende Bedienelement erreichbar (hinter dem Fragezeichen rechts unten in der Ecke, wenn du auf „Barrierefreiheit“ klickst).

Die getroffenen Einstellungen bleiben im Browser für die nächste Nutzung gespeichert.

3. Nicht oder nur teilweise barrierefreie Inhalte

Die folgende Auflistung benennt die uns bekannten Barrieren und die jeweils verletzten WCAG-Erfolgskriterien. Die Reihenfolge folgt der Schwere und der Häufigkeit der Auswirkung auf Nutzer:innen.

Darstellung auf kleinen Bildschirmen (Reflow)

Die Anwendung unterstützt derzeit eine responsive Darstellung erst ab einer Mindestbreite von 360 Pixeln. Bei Geräten oder Fensterbreiten von weniger als 360 Pixeln (z. B. ältere Smartphone-Modelle mit einer Standardbreite von 320 Pixeln) kann es zu Darstellungsfehlern, abgeschnittenen Inhalten oder erzwungenem horizontalen Scrollen kommen. Dies widerspricht dem WCAG-Erfolgskriterium 1.4.10 (Umbruch / Reflow).

3.1 — Landing page (splint.schule)

Überschriften-Struktur

• WCAG 1.3.1 (Info und Beziehungen) / WCAG 2.4.6 (Überschriften und Beschriftungen): Auf einzelnen Landing pages fehlen Überschriften der ersten Ebene (<h1>) bzw. werden Überschriften-Ebenen übersprungen (z. B. <h1> direkt gefolgt von <h3>). Mehrere Versionsblöcke auf der Startseite tragen identische <h1>-Überschriften, obwohl es sich nicht um eigenständige Inhaltsbereiche handelt. Auch im Footer ist die Hierarchie teilweise umgekehrt.

Farbkontraste

• WCAG 1.4.11 (Nicht-Text-Kontrast): Einige Bedien- und Statuselemente (z. B. die Toggle-Buttons im Cookie-Banner, Eingabefeld-Rahmen) liegen unter dem Mindestwert von 3 : 1 gegen ihren Hintergrund. Hinweis: Slider-Pfeile und Paginierungs-Punkte des Banner-Karussells auf der Startseite werden programmatisch als dekorativ ausgewiesen (aria-hidden="true" / role="presentation") und fallen damit aus der WCAG-1.4.11-Anforderung heraus; eine UX-seitige Stärkung des Sehkontrastes bleibt davon unberührt sinnvoll.

Bewegte und animierte Inhalte

• WCAG 2.2.2 (Pausieren, stoppen, ausblenden): Der animierte Banner-Slider auf der Startseite pausiert automatisch, sobald sich die Maus über dem Slider befindet oder ein Element des Sliders den Tastatur-Fokus erhält. Ein expliziter Pause-Button zum dauerhaften Anhalten des automatischen Wechsels existiert aktuell nicht — für Nutzer:innen, die weder Maus noch Tastatur-Fokus auf den Slider richten (z. B. Switch-Control- oder Eye-Tracker-Nutzer:innen), bleibt damit eine Barriere.

3.2 — SPLINT Web-App (eingeloggter Bereich)

Die App-Seite hat den größten Funktionsumfang und entsprechend die meisten bekannten Befunde:

Formulare

• WCAG 3.3.1 / WCAG 4.1.3 (Fehleridentifikation / Statusmeldungen): Fehlermeldungen unter Formularfeldern werden derzeit visuell ausgegeben, sind aber nicht über role="alert" oder aria-live als Live-Regionen markiert und nicht über aria-describedby mit dem zugehörigen Eingabefeld verknüpft. Screenreader bemerken dynamisch erscheinende Fehler daher nicht automatisch.
• WCAG 4.1.2 (Name, Rolle, Wert): Eingabefelder mit Validierungsfehlern erhalten zur Zeit kein aria-invalid="true" — die fehlerhafte Markierung ist visuell vorhanden, aber Screenreader können den Zustand nicht zuverlässig identifizieren.
• WCAG 1.3.1: Checkbox-Gruppen sind selten in <fieldset> mit <legend> zusammengefasst. Die Gruppen-Zugehörigkeit ist für Screenreader oft nicht erkennbar.

Dialoge und Modals

• WCAG 2.1.2 (Keine Tastaturfalle — umgekehrte Variante): Schließen über die Esc-Taste ist nicht durchgängig sichergestellt.

Interaktive Elemente ohne Tastaturzugang

• WCAG 2.1.1 / WCAG 4.1.2: Einige wenige Bedienelemente sind als generische <div> mit Klick-Handler implementiert. Diese Elemente sind weder per Tab erreichbar noch mit Enter/Space bedienbar. Konkret betrifft das u. a. das Drag-and-Drop-Verschieben von Fördermaßnahmen sowie das Auswählen von Antwortoptionen in Beobachtungen. Diese Funktionen sind aktuell nicht zuverlässig per Tastatur bedienbar.

Icon-only Buttons ohne Beschriftung

• WCAG 4.1.2 (Name, Rolle, Wert): Mehrere Buttons, die ausschließlich ein Icon enthalten (z. B. Optionen-Menü, Hilfe-Symbole, X-Schließen-Symbole an Dialogfeldern, Pin- und Edit-Aktionen an Karten), tragen kein aria-label. Screenreader kündigen die Funktionsbeschreibung allerdings über die Tooltips an.

Farbkontraste

Der hell-grüne Akzent wird auch im eingeloggten Bereich (insbesondere in Fortschritts-Indikatoren und in Diagrammen) als Background mit weißer Beschriftung verwendet. Kontrast 2.36 : 1. An weiteren Stellen treten ähnliche Muster auf, typisch sind Hover-Zustände mit oranger Schrift auf hellen Hintergründen sowie helle Grau-Töne in Hilfstexten, deaktivierten Eingabefeldern und einzelnen State-Indikatoren. Für die App lässt sich ein Hochkontrast-Modus über das Barrierefreiheits-Widget (Abschnitt 2.1) aktivieren.

Verwendung von Farbe als alleinigem Bedeutungsträger

WCAG 1.4.1 (Benutzung von Farbe): Einige Zustände werden größtenteils über Farbe vermittelt:

• Angepinnte Kacheln (Pin-Icon)
• Ausgewählte Förderbereiche und Passwort-Anforderungs-Indikatoren — der Wechsel erfolgt nur über die Textfarbe (hellgrau ↔ grün)

Überschriften-Struktur

Analog zu 3.1 — auch in der App treten Multi-<h1>-Seiten und Skip-Levels auf, insbesondere in einigen Förderplan-Bearbeitungs-Seiten. Zusätzlich zeigen einzelne Bereiche strukturell uneinheitliche Hierarchien (z. B. mehrere <h2> auf gleicher Ebene, obwohl inhaltlich untergeordnet) — u. a. beim Förderplan-Erstellen und in der Beobachtungs-Anfrage.

Reflow und Zoom

• WCAG 1.4.10 (Automatischer Umbruch — Reflow): Bei einer Fensterbreite von 320 Pixeln (Mobile-Standard) können lange Begriffe im Slider abgeschnitten dargestellt werden. Auch in größeren Baumstrukturen — etwa in der Beobachtungs-Erstellung — können bei dieser Breite einzelne Checkboxen außerhalb des sichtbaren Bereichs liegen.

Textgröße ändern

WCAG 1.4.4 (Textgröße ändern): Bei einer Vergrößerung auf 200 % über die Browser-Zoom-Funktion (Fensterbreite 1280 px) überdeckt die Kopfleiste das Hilfe-/Feedback-Element. Das Barrierefreiheits-Widget (Abschnitt 2.1) erlaubt zusätzlich eine direkte Schriftgrößen-Anpassung, die nicht zu diesem Layout-Konflikt führt.

Anpassung an Browser-Benutzerpräferenzen

• EN 301 549 11.7 (Benutzerpräferenzen): Anpassungen, die Nutzer:innen im Browser an Schriftfarbe, Schriftgröße oder Hintergrund-Farbe vornehmen, werden von der App nicht durchgängig respektiert. Statusmeldungen und Dialogfelder verlieren bei aktivierten Browser-Custom-Farben ihre Begrenzung, einzelne grafische Elemente passen sich nicht an. Als alternativer Pfad bietet das Barrierefreiheits-Widget (Abschnitt 2.1) eine direkte Anpassung von Schriftgröße, Schriftart und Kontrast innerhalb der Anwendung.

3.3 — PDF-Förderpläne und weitere PDF-Exporte

Die aus der App heraus erzeugten PDF-Förderpläne und vergleichbaren PDF-Exporte sind derzeit nicht barrierefrei. Konkret fehlen den erzeugten PDFs u. a. die folgenden Voraussetzungen für die Konformität nach PDF/UA:

• Tag-Strukturen (logische Lese-Reihenfolge, Überschriften, Listen, Tabellen) sind nicht ausgezeichnet
• Die Sprache des Dokuments ist nicht programmatisch gesetzt
• Alternativtexte für eingebettete Grafiken fehlen

4. Bekannte Grenzen dieser Erklärung und ausstehende Prüfungen

Im Sinne der Ehrlichkeit listen wir auf, welche Prüfungen zum Stand dieser Erklärung mit aktuellem Code-Stand noch nicht stattgefunden haben:

• Die externe KBIT-Prüfung von 2024 enthält wertvolle Runtime-Beobachtungen — Teile der App wurden aber seither überarbeitet. Eine erneute systematische Runtime-Prüfung haben wir noch nicht abgeschlossen.
• Aktuelles manuelles Testen mit Screenreadern (NVDA, VoiceOver, TalkBack) auf dem heutigen Code-Stand: steht aus.
• Tastatur-Testing über vollständige aktuelle User-Flows: komplette Prüfung im August 2025, danach punktuell neu geprüft.
• Bewertung der dynamischen Zustände (Hover, Active, Selected, Disabled-States mit Opacity-Modifikationen): nur teilweise erfasst.

5. Erstellung dieser Erklärung

• Erstellungsdatum: 05. August 2026
• Letzte Aktualisierung: 05. August 2026

Methode: Selbstbewertung auf Basis von WCAG 2.1 AA und EN 301 549, gestützt auf:

1. Externe Prüfung durch das Kompetenzzentrum Barrierefreie IT (KBIT) der IT.NRW vom 11.–22. Oktober 2024 (Stichprobe von acht repräsentativen Seiten der App nach KBIT-Prüfschema — enthält Runtime- und manuelle Befunde)
2. Internes statisches Code-Audit vom Mai 2026 (eslint-plugin-jsx-a11y-Baseline, Komponenten-Inventar, Token-Kontrast-Analyse, manuelle Komponenten-Inspektion)

Werkzeuge: eslint-plugin-jsx-a11y, WCAG-2.1-Luminanz-Formel für Kontrast-Berechnung; KBIT-Prüfschema

6. Feedback und Kontakt

Wenn dir Barrieren auffallen oder du Inhalte in einer alternativen Form benötigst, melde dich bei uns. Wir freuen uns über jede Rückmeldung und antworten in der Regel innerhalb von fünf Werktagen.

Inklusion-Digital GmbH
Muskauer Str 44
10997 Berlin

E-Mail: barrierefreiheit@inklusion-digital.de

7. Stand dieser Erklärung

05. August 2026