Gutachten
Zugänglichkeits-Analyse
Blindheit
Kaum nutzbar
Fehlende Alternativtexte, unzugängliche Diagramme/Canvas, mangelhafte Semantik, Tastaturprobleme und fehlende Statusmeldungen schränken Screenreader-Nutzung massiv ein.
Sehbehinderung
Kaum nutzbar
Niedrige Kontraste, Nutzung von Farbe als alleiniges Merkmal, Probleme bei Vergrößerung und Textabstand sowie ignorierte Benutzerpräferenzen erschweren die Nutzung stark.
Hörbehinderung
Mit Hindernissen nutzbar
Die Webinhalte selbst sind überwiegend nutzbar, aber fehlende Gebärdensprachvideos und unvollständige Informationen in Leichter Sprache mindern die Zugänglichkeit.
Motorische Behinderung
Kaum nutzbar
Wesentliche Bereiche sind nicht oder nur schlecht tastaturbedienbar, Fokusführung ist problematisch und der Fokus ist schlecht sichtbar.
Lernbehinderung
Mit Hindernissen nutzbar
Automatische Wechsel ohne Stopp, unklare Beschriftungen, komplexe Diagramme und fehlende Leichte-Sprache-Erläuterungen erschweren das Verstehen.
Neurodivergenz
Mit Hindernissen nutzbar
Automatische Karussells, lange und unlogische Fokusreihenfolgen sowie schwer verständliche Strukturen können Aufmerksamkeit und Orientierung stark beeinträchtigen.
Hinweis: Diese Einschätzung mit generativer KI basiert auf den Informationen aus diesem Gutachten. Künstliche Intelligenz kann Inhalte nicht automatisch barrierefrei machen oder Prüfungen durchführen. Behinderungen sind komplex und mehrschichtig, weshalb diese Analysen nicht zutreffen müssen.
Empfehlung
Fehlende Alternativtexte, fehlende semantische Struktur, unzureichende Tastatur- und Fokussteuerung sowie mangelnde Kontrastverhältnisse müssen behoben werden. Zusätzlich sind Benutzerpräferenzen zu berücksichtigen und die Erklärung zur Barrierefreiheit inklusive leicht verständlicher und vollständig verfügbaren Informationen (auch Gebärdensprache) nachzurüsten.
| Kriterium | Status | Notizen |
|---|---|---|
|
4.9.1.1.1.a Alternativtexte für Bedienelemente – Canvas-Inhalte |
nicht bestanden | Canvas-Inhalte benötigen aussagekräftige Textalternativen oder eine textbasierte Darstellung, damit Screenreader die dargestellten Informationen übertragen können. |
|
4.9.1.1.1.a Alternativtexte für Bedienelemente – Dialogschalter |
nicht bestanden | Grafische Schalter wie der Dialogabschluss benötigen eine sprechende Alternative (z. B. aria-label="Dialog schließen"), damit die Funktion für Screenreader-Nutzende verständlich wird. |
|
4.9.1.1.1.b Alternativtexte für Grafiken und Objekte – Diagramme ohne Alternative |
nicht bestanden | Die Rastergrafiken (Canvas) in den Kennzahlen müssen durch Textalternativen oder tabellarische Alternativen ergänzt werden, damit blinde Nutzer die Daten erfassen können. |
|
4.9.1.1.1 Alternativtexte für Grafiken und Objekte – Zufriedenheitsgrafik |
nicht bestanden | Die Grafiken, die Zufriedenheitswerte darstellen, benötigen Alternativtexte oder textbasierte Beschreibungen, da die Informationen derzeit nur visuell vermittelt werden. |
|
4.9.1.3.1.a HTML-Strukturelemente für Überschriften – nicht ausgezeichnete Überschriften |
nicht bestanden | Visuell erkennbare Überschriften müssen per HTML-Hierarchie ausgezeichnet werden (z. B. h2, h3), damit die Struktur für Screenreader erkennbar ist. |
|
4.9.1.3.2 Bedeutungsvolle Reihenfolge – Hinweis erst nach interaktiver Karte |
nicht bestanden | Hinweise wie „Bitte wählen Sie …“ müssen vor der interaktiven Karte erscheinen, damit Tastaturnutzer und Screenreader nachvollziehen können, was zu tun ist. |
|
4.9.1.3.2 Bedeutungsvolle Reihenfolge – Endlosschleife im Lesemodus |
nicht bestanden | Elemente, die sich in der Lesemodus-Tab-Reihenfolge nicht verlassen lassen, müssen so angepasst werden, dass der Fokus nicht in Endlosschleifen hängen bleibt. |
|
4.9.1.3.2 Bedeutungsvolle Reihenfolge – Reihenfolge von Überschrift und Registerkarten |
nicht bestanden | Zusammengehörige Inhalte wie Überschriften und Registerkarten dürfen nicht durch andere Elemente getrennt vorgelesen werden; Fokussequenz und DOM-Reihenfolge müssen zusammenpassen. |
|
4.9.1.4.1 Benutzung von Farbe – Go-live-Status nur durch Farbe |
nicht bestanden | Die inhaltlich wichtigen Farbcodierungen (u. a. Go-live-Status) müssen durch zusätzliche Kennzeichnungen oder ausreichend kontrastierte Ausprägungen ergänzt werden. |
|
4.9.1.4.1 Benutzung von Farbe – Registerkartenstatus nur durch Farbe erkennbar |
nicht bestanden | Der aktuelle Registerkartenzustand benötigt weitere visuelle Hinweise (Unterstreichung, Symbol) und/oder einen Kontrast von mindestens 3:1, damit fehlsichtige Nutzer die Auswahl erkennen. |
|
4.9.1.4.1 Benutzung von Farbe – Verfügbarkeitslegende ohne Alternativinformation |
nicht bestanden | Farben in der Verfügbarkeitslegende müssen durch Text oder Symbole ergänzt werden, damit auch Nutzer mit Farbsehschwäche die Bedeutungen erkennen. |
|
4.9.1.4.1 Benutzung von Farbe – Auswahl nur durch Farbwechsel ersichtlich |
nicht bestanden | Auswahlzustände müssen durch zusätzliche Merkmale wie Rahmen oder Symbole erkennbar sein; der einfache Farbwechsel bei Kontrast 2,3:1 reicht nicht aus. |
|
4.9.1.4.3 Kontrast (Minimum) – Filtertexte unter 4,5:1 |
nicht bestanden | Die markierten Texte weisen Kontrastverhältnisse unter 4,5:1 auf; Farben müssen angepasst oder kontrastverstärkt werden, damit sie fehlsichere Nutzer auch lesen können. |
|
4.9.1.4.4 Textgröße ändern |
nicht bestanden | Vergrößerungen (bis 200 %) müssen funktionieren; die Veränderungen im Diagramm sind bei vergrößerter Ansicht nicht mehr nachvollziehbar. |
|
4.9.1.4.11 Nicht-Text-Kontrast – Balkendiagramme |
nicht bestanden | Die Balken im Diagramm benötigen einen Kontrast von mindestens 3:1 zum Hintergrund, sonst können sehbehinderte Nutzer sie nicht unterscheiden. |
|
4.9.1.4.13 Eingeblendeter Inhalt bei Darüberschweben (Hover) oder Fokus – verschwindende Inhalte |
nicht bestanden | Hover-Inhalte müssen sich halten lassen, ohne dass der Mauszeiger wegbewegt werden muss; die Anzeige muss verwerfbar, überfahrbar und beständig sein. |
|
4.9.2.1.1 Tastatur – Detailinfos nur per Maus verfügbar |
nicht bestanden | Alle im Diagramm abrufbaren Detailinformationen müssen auch per Tastatur (z. B. via Fokus oder Tastenkombination) zugänglich sein. |
|
4.9.2.1.1 Tastatur – Deutschlandkarte nicht bedienbar |
nicht bestanden | Die interaktive Deutschlandkarte kann weder per Tab noch per Tastatur genutzt werden; eine vollständig tastaturbedienbare Alternative (z. B. über Listen) muss geschaffen werden. |
|
4.9.2.1.1 Tastatur – Filterbereich unerreichbar |
nicht bestanden | Der gelb markierte Filterbereich muss per Tab erreichbar und bedienbar sein, damit Tastaturnutzer auswählen können, was angezeigt wird. |
|
4.9.2.2.2 Pausieren, stoppen, ausblenden – automatische Wappenwechsel |
nicht bestanden | Die automatischen Karussells und Wappenwechsel müssen durch ein Bedienelement anhaltbar sein, damit Benutzer mit Konzentrationsstörungen nicht abgelenkt werden. |
|
4.9.2.4.1 Blöcke überspringen – fehlender main-Landmark |
nicht bestanden | Der Hauptinhalt (main) und weitere Bereiche benötigen HTML5-Elemente oder WAI-ARIA Landmarks, damit Screenreader direkt zu repetitiven Blöcken springen können. |
|
4.9.2.4.3 Fokus-Reihenfolge – Canvas Tab-Reihenfolge zu lang |
nicht bestanden | Canvas-Elemente liefern über 200 Tab-Schritte; es muss eine Möglichkeit geben, solche Bereiche zu überspringen oder tabelliert zu strukturieren, damit Tastaturnutzer nicht überfordert werden. |
|
4.9.2.4.3 Fokus-Reihenfolge – nicht interaktive Elemente werden fokussiert |
nicht bestanden | Nicht interaktive Elemente dürfen nicht in der Tab-Reihenfolge landen; stattdessen muss nur interaktiven Komponenten der Fokus vorbehalten sein. |
|
4.9.2.4.3 Fokus-Reihenfolge – Tab-Umbau nicht möglich |
nicht bestanden | Diagramme müssen so aufgebaut werden, dass ein Vorwärts- und Rückwärtsspringen per Tab/T Shift-Tab möglich ist; aktuell ist dies nur vorwärts möglich. |
|
4.9.2.4.6 Überschriften und Beschriftungen – ‚previous‘/‘next‘ ohne Kontext |
nicht bestanden | Schaltflächen sollten aussagekräftige Beschriftungen erhalten, z. B. „Zur vorherigen OZG-Leistung“, damit Screenreader den Zweck verstehen. |
|
4.9.2.4.6 Überschriften und Beschriftungen – Nummerierung ohne Kontext |
nicht bestanden | Seitennummern benötigen zusätzliche Informationen (z. B. aria-label="Seite 5 von 16") damit Nutzende nachvollziehen können, welche Funktion die Links haben. |
|
4.9.2.4.7 Fokus sichtbar |
nicht bestanden | Der Tastaturfokus muss sichtbar sein und einen Kontrast von mindestens 3:1 bieten, damit motorisch eingeschränkte Nutzer die aktuelle Position erkennen. |
|
4.9.3.3.1 Fehlerkennzeichnung – Fehlermeldungen nicht verknüpft |
nicht bestanden | Fehlermeldungen müssen mit aria-describedby oder innerhalb von label verknüpft werden, damit Screenreader direkt beim Feld vorlesen können, was falsch ist. |
|
4.9.3.3.2 Beschriftungen (Labels) oder Anweisungen – fehlende Beschriftung einer Auswahlliste |
nicht bestanden | Die Auswahlliste benötigt eine sichtbare und programmatisch ermittelte Beschriftung, damit Nutzer erkennen können, worauf sich die Auswahl bezieht. |
|
4.9.3.3.2 Beschriftungen (Labels) oder Anweisungen – Maximallänge nicht programmiert |
nicht bestanden | Maximallänge und Zeichenanzahl müssen per aria-describedby oder als Teil des Labels mit dem Eingabefeld verknüpft werden, damit Screenreader die Begrenzung vorlesen. |
|
4.9.4.1.2 Name, Rolle, Wert – Registerkarten ohne ARIA |
nicht bestanden | Registerkarten sollten semantisch korrekt umgesetzt werden (z. B. role="tablist"/"tab"/"tabpanel") mit den dazugehörigen ARIA-Attributen, damit Name und Rolle für Screenreader ersichtlich sind. |
|
4.9.4.1.2 Name, Rolle, Wert – Schalter ohne Name oder Wert |
nicht bestanden | Schalter müssen mit einem Namen und dem korrekten Wert (z. B. aria-pressed mit verständlichem Text) ausgestattet sein; derzeit fehlt diese semantische Verknüpfung. |
|
4.9.4.1.2 Name, Rolle, Wert – div als Bedienelement ohne ARIA |
nicht bestanden | Mit JavaScript zu Schaltern umfunktionierte div-Elemente benötigen durchgehend aria-Attribute oder müssen durch native Elemente ersetzt werden. |
|
4.9.4.1.2 Name, Rolle, Wert – Keine aria-current auf Registerkarten |
nicht bestanden | Aktuelle Auswahl muss per aria-current oder ähnlichem angezeigt werden, damit Screenreader den aktuellen Zustand erkennen. |
|
4.9.4.1.3 Statusmeldungen – fehlendes Feedback über Änderungen |
nicht bestanden | Statusmeldungen (aria-live) sollten ergänzt werden, damit Screenreader bei Änderung einer Ansicht oder Datenübergabe informiert werden, ohne dass Fokus gewechselt werden muss. |
|
4.9.6 Konformitätsanforderungen der WCAG |
nicht bestanden | Die geprüften Seiten erfüllen nicht durchgehend alle Anforderungen der WCAG 2.1 A/AA (u. a. Tastaturzugänglichkeit, Kontrast, alternativer Text); derzeit ist die Seite nicht konform. |
|
4.11.7 Benutzerpräferenzen – fehlender Kontrast bei benutzerdefinierten Farben |
nicht bestanden | Bei benutzerdefinierten Schrift- und Hintergrundfarben wird der Kontrast zu gering; Elemente sollten zusätzlich eine Hintergrundfarbe oder Kontur erhalten, sodass der Kontrast auch bei geänderten Systemfarben erhalten bleibt. |
|
4.12.1.2 Barrierefreie Dokumentation – Erklärung zur Barrierefreiheit nicht vollständig barrierefrei |
nicht bestanden | Die Erklärung zur Barrierefreiheit muss die gleiche Barrierefreiheit wie die restliche Website vorweisen; die vorhandenen Auffälligkeiten (Alternativtexte, Struktur etc.) müssen behoben werden. |
|
5.5 Erläuterungen in Gebärdensprache – nicht vorhanden |
nicht bestanden | Es fehlen Videos zu den wesentlichen Inhalten, Navigation und Erklärung zur Barrierefreiheit; entsprechende Gebärdensprachvideos müssen ergänzt werden. |
| Kriterium | Status | Notizen |
|---|---|---|
|
4.9.1.1.1.a Alternativtexte für Bedienelemente – Navigationselemente mit englischsprachigem Alternativtext |
im Wesentlichen bestanden | Die Alternativtexte von Navigationsschaltflächen müssen deutsch sein und den Inhalt beschreiben (z. B. aria-label="Nächste OZG-Leistung"). |
|
4.9.1.1.1 Alternativtexte für Grafiken und Objekte – Externer Link Hinweisgrafik |
im Wesentlichen bestanden | Die grafische Kennzeichnung für externe Links benötigt eine Textalternative, damit Nutzer ohne visuelle Wahrnehmung verstehen, dass es sich um einen externen Link handelt. |
|
4.9.1.1.1.c Leere alt-Attribute für Layoutgrafiken |
im Wesentlichen bestanden | Dekorative Grafiken sollen mit leeren alt-Attributen versehen werden, um Doppelungen in der Sprachausgabe zu vermeiden. |
|
4.9.1.3.1.a HTML-Strukturelemente für Überschriften – Überspringen von Überschriftenebenen |
im Wesentlichen bestanden | Überschriftenebenen wie h2 dürfen nicht unmotiviert übersprungen werden, um die logische Struktur nachvollziehbar zu halten. |
|
4.9.1.3.1.a HTML-Strukturelemente für Überschriften – fehlende h1-Auszeichnung |
im Wesentlichen bestanden | Die Hauptüberschriften (h1) müssen korrekt ausgezeichnet sein, damit Screenreader die Seite eindeutig einordnen können. |
|
4.9.1.3.1.a HTML-Strukturelemente für Überschriften – gleiche Ebene für untergeordnete Inhalte |
im Wesentlichen bestanden | Untergeordnete Inhalte dürfen nicht auf derselben Hierarchieebene wie übergeordnete stehen; eine strukturierte Auszeichnung verbessert die Lesbarkeit für assistive Technologien. |
|
4.9.1.3.1.b HTML-Strukturelemente für Listen – fehlende Listenkennzeichnung |
im Wesentlichen bestanden | Inhaltlich als Listen dargestellte Bereiche müssen mit ul/ol/li ausgezeichnet werden, damit Screenreader Zielbeziehungen interpretieren können. |
|
4.9.1.3.1.b HTML-Strukturelemente für Listen – getrennte Listen statt einer zusammenhängenden |
im Wesentlichen bestanden | Semantisch zusammengehörende Listen dürfen nicht als mehrere einzelne Listen kodiert werden; stattdessen ist eine einzige Liste mit korrektem Markup zu verwenden. |
|
4.9.1.3.1.d Inhalte gegliedert – Absätze mit br-Elementen |
im Wesentlichen bestanden | Absätze sollten mit p-Elementen ausgezeichnet und Abstände per CSS realisiert werden, da doppelte br-Elemente Screenreader mit Leerausgaben stören. |
|
4.9.1.3.2 Bedeutungsvolle Reihenfolge – Teaser mit Bild vor Text |
im Wesentlichen bestanden | Texte, die für das Verständnis der Teaser benötigt werden, müssen im Quelltext vor den zugehörigen Grafiken stehen, damit die Leseabfolge erhalten bleibt. |
|
4.9.1.4.2 Audio-Steuerelemente – kontrastarme Fließtextlinks |
im Wesentlichen bestanden | Links, die nur über Farbe hervorstechen, benötigen eine zusätzliche Hervorhebung oder einen Kontrast von mindestens 3:1 zum umgebenden Text. |
|
4.9.1.4.11 Nicht-Text-Kontrast – überlagernde Bedienelemente in verschiebbarer Karte |
im Wesentlichen bestanden | Bei verschobenen Karten überlagern sich Elemente; um den Kontrast zu gewährleisten, sind klare Konturen oder Hintergrundverläufe nötig. |
|
4.9.1.4.12 Textabstand |
im Wesentlichen bestanden | Die geforderten Abstände führen lokal zu Überlagerungen; Layout muss so gestaltet werden, dass erhöhte Zeilen-, Zeichen- und Wortabstände nicht zu Layoutverlust führen. |
|
4.9.1.4.13 Eingeblendeter Inhalt bei Darüberschweben (Hover) oder Fokus – Erklärung nicht schließbar |
im Wesentlichen bestanden | Fokusbasierte Inhalte dürfen beim Verlassen des Fokus nicht die Darstellung anderer Inhalte blockieren; sie müssen alternativ auch mit ESC oder einem Schließen-Link austretbar sein. |
|
4.9.2.1.1 Tastatur – Diagrammdetails teilweise nur per Hover |
im Wesentlichen bestanden | Die Informationen sind zwar faktisch im Diagramm enthalten, aber ohne Tastaturfokus nicht einsehbar; die Interaktion muss auch über die Tastatur funktionieren. |
|
4.9.2.1.1 Tastatur – Kartenansicht durch Hover gesteuert |
im Wesentlichen bestanden | Hover-Effekte auf Textelementen dürfen nicht die Ansicht verändern, wenn diese nur via Tastatur gesteuert werden; die Änderung muss alternativ über Tastaturtrigger auslösbar sein. |
|
4.9.2.4.1 Blöcke überspringen – Navigationsbereiche ohne Beschriftung |
im Wesentlichen bestanden | Mehrfach verwendete nav-Elemente benötigen eindeutige aria-labels, damit Tastaturnutzer erkennen, welchem Zweck jeder Bereich dient; z. B. aria-label="Seitennavigation". |
|
4.9.3.3.2 Beschriftungen (Labels) oder Anweisungen – unklare Labels |
im Wesentlichen bestanden | Labels wie „1“ sind für Screenreader nicht verständlich; stattdessen müssen Formularelemente z. B. mit „Bewertung 1 von 5 Sternen“ beschriftet werden. |
|
4.9.4.1.2 Name, Rolle, Wert – Dialogtitel fehlt |
im Wesentlichen bestanden | Dialogfenster benötigen einen Titel (aria-labelledby), damit Blinde wissen, welches Fenster geöffnet wurde. |
|
4.9.4.1.3 Statusmeldungen – englischsprachige Zoommeldung |
im Wesentlichen bestanden | Statusmeldungen müssen in der Sprache des Webauftritts erfolgen (z. B. „Zoom wurde auf Level 2 vergrößert“), damit sie verständlich bleiben. |
|
4.11.7 Benutzerpräferenzen – benutzerdefinierte Schriftgröße wird ignoriert |
im Wesentlichen bestanden | Die Website muss relative Einheiten (z. B. rem, %) nutzen, damit Nutzerdefinierte Schriftgrößen (z. B. 24 px) übernommen werden. |
|
5.2 Erklärung zur Barrierefreiheit – fehlende Angaben zu den Gründen |
im Wesentlichen bestanden | Die Erklärung muss mindestens die Gründe für die nicht barrierefreie Gestaltung enthalten. |
|
5.4 Erläuterungen in Leichter Sprache – fehlende Erläuterungen |
im Wesentlichen bestanden | Die Texte in Leichter Sprache müssen die wesentlichen Inhalte der Erklärung zur Barrierefreiheit erläutern; aktuell fehlen diese Ausführungen. |
| Kriterium | Status | Notizen |
|---|---|---|
|
4.9.1.3.3 Sensorische Eigenschaften |
bestanden | Anweisungen nutzen keine ausschließlich auf sensorischen Merkmalen basierenden Informationen. |
|
4.9.1.3.4 Ausrichtung |
bestanden | Die Inhalte sind nicht auf eine einzige Bildschirmorientierung beschränkt. |
|
4.9.1.4.10 Automatischer Umbruch (Reflow) |
bestanden | Inhalte können ohne Informations- oder Funktionsverlust umgebrochen werden. |
|
4.9.2.1.2 Keine Tastaturfalle |
bestanden | Der Fokus lässt sich aus jedem Element wieder entfernen. |
|
4.9.2.1.4 Tastaturkürzel |
bestanden | Tastaturkürzel lassen sich abschalten und/oder sind nur bei Fokus aktiv. |
|
4.9.2.4.2 Seite mit Titel |
bestanden | Die Seite verfügt über einen aussagekräftigen Titel. |
|
4.9.2.4.4 Linkzweck (im Kontext) |
bestanden | Links verfügen über kontextuelle Informationen oder aussagekräftige Texte, die ihren Zweck erläutern. |
|
4.9.2.4.5 Verschiedene Möglichkeiten |
bestanden | Es gibt mehrere Methoden, um die Site innerhalb des Webseitenverbunds zu erreichen. |
|
4.9.2.5.1 Zeigergesten |
bestanden | Mehrpunktgesten sind nicht erforderlich, alle Funktionen sind mit einem einzelnen Zeiger bedienbar. |
|
4.9.2.5.2 Abbruch der Zeigeraktion |
bestanden | Zeigeraktionen lassen sich mindestens mit den üblichen Methoden abbrechen oder rückgängig machen (Down/Up). |
|
4.9.2.5.3 Beschriftung (Label) im Namen |
bestanden | Beschriftungen sind im (programmgesteuerten) Namen enthalten. |
|
4.9.3.1.1 Sprache der Seite |
bestanden | Die Seitensprache ist per lang-Attribut festgelegt. |
|
4.9.3.2.1 Bei Fokus |
bestanden | Fokusänderungen lösen keine unerwarteten Kontextwechsel aus. |
|
4.9.3.2.2 Bei Eingabe |
bestanden | Einstellungen ändern den Kontext nur, wenn dies vorher angekündigt wurde. |
|
4.9.3.2.3 Konsistente Navigation |
bestanden | Wiederholte Navigationsmechanismen behalten beim Wechsel die Reihenfolge bei. |
|
4.9.3.2.4 Konsistente Kennzeichnung |
bestanden | Elemente mit gleicher Funktion sind konsistent benannt. |
|
4.9.3.3.3 Vorschlag bei Fehler |
bestanden | Fehlerkorrekturhinweise werden bereitgestellt, sofern bekannt. |
|
4.9.4.1.1 Syntaxanalyse |
bestanden | Validitätsprüfungen zeigen keine relevanten Syntaxfehler. |
|
5.3 Feedback-Mechanismus |
bestanden | Ein Feedbackmechanismus ist vorhanden und beschreibt die Kontaktmöglichkeit. |