Kurzzusammenfassung
- Auftraggeber
- DigitalService des Bundes
- Prüforganisation
- Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik
- Stadt
- Berlin
- Prüfart
- Vereinfachte Überwachung
Zugänglichkeits-Analyse
Blindheit
Mit Hindernissen nutzbar
Mehrere gravierende Screenreader-Probleme (Alternativtexte, Linkzweck, Struktur, Reihenfolge, Seitentitel) beeinträchtigen Orientierung und Formularnutzung deutlich.
Sehbehinderung
Mit Hindernissen nutzbar
Fehlende sichtbare Fokusindikatoren und Skiplinks erschweren Tastaturnutzung, ansonsten sind primär semantische statt visuelle Mängel beschrieben.
Hörbehinderung
Fast barrierefrei
Es gibt keine Hinweise auf Audioinhalte; die beschriebenen Probleme betreffen überwiegend Screenreader, Tastatur und Formulare.
Motorische Behinderung
Mit Hindernissen nutzbar
Navigation ist grundsätzlich per Tastatur möglich, aber fehlende Skiplinks, teilweise Fokusprobleme und fehlende Escape-Funktion in der Navigation erschweren die Bedienung deutlich.
Lernbehinderung
Mit Hindernissen nutzbar
Unklare Linktexte, unzureichende Fehlerkennzeichnung und Pflichtfeldmarkierung können Verständnis und Fehlerkorrektur erschweren, die Grundstruktur ist aber im Wesentlichen vorhanden.
Neurodivergenz
Mit Hindernissen nutzbar
Mangelnde Orientierungshilfen (Seitentitel, Skiplinks, teils Überschriftenstruktur) und unklare Links können die kognitive Last erhöhen, ohne die Seite völlig unbenutzbar zu machen.
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.
Die Barrierefreiheit lässt sich verbessern, indem aussagekräftige Alternativtexte und Linktexte gesetzt, Skiplinks und die Escape-Funktion ergänzt, Fokusindikatoren sichtbar gemacht, Fehlermeldungen und Pflichtfelder eindeutig an der Oberfläche dargestellt sowie die Barrierefreiheitserklärung gemäß §7 BITV vervollständigt werden.
| Kriterium | Status | Notizen |
|---|---|---|
|
9.2.4.1 Blöcke überspringen |
nicht bestanden | Skiplinks müssen am Seitenanfang eingefügt werden, sodass Tastaturnutzende wiederkehrende Bereiche überspringen können (z. B. durch einen fokussierbaren Link href="#maincontent"). |
|
9.2.1.1 Tastatur |
nicht bestanden | Die aufklappbare Seitennavigation muss sich auch über die Escape-Taste schließen lassen und danach der Fokus zur auslösenden Schaltfläche zurückkehren. |
|
9.3.3.1 Fehlerkennzeichnung |
nicht bestanden | Fehlermeldungen dürfen nicht nur als kurzlebige Tooltips erscheinen, sie müssen dauerhaft sichtbar sein und programmatisch mit dem jeweiligen Eingabefeld (z. B. aria-describedby) verknüpft werden. |
|
9.1.1.1 Nicht-Text-Inhalt |
nicht bestanden | Das Logo benötigt einen präzisen Alternativtext, der Name und Funktion (z. B. Link zur Startseite) beschreibt, damit Screenreader-Nutzende die Orientierung erhalten. |
|
9.2.4.4 Linkzweck (im Kontext) |
nicht bestanden | Entweder Logo und Text in einem Link zusammenfassen oder nur einen Link anbieten, um redundante doppelte Sprünge für Tastatur- und Screenreader-Nutzende zu vermeiden. |
|
9.2.4.4 Linkzweck (im Kontext) |
nicht bestanden | Der Linktext muss den Zielinhalt oder Zweck eindeutig benennen, z. B. „Startseite des Servicestandard“, statt generischer Begriffe wie „Servicestandard“. |
|
9.1.3.1 Info und Beziehungen |
nicht bestanden | Wichtige Zahlen, etwa „Kriterium 1 von 13“, müssen Teil des Linktextes oder in einem aria-label sein, damit Screenreader-Nutzende Reihenfolge und Anzahl erkennen. |
|
9.3.3.2 Beschriftungen (Labels) oder Anweisungen |
nicht bestanden | Pflichtfelder sind sowohl im Code (required oder aria-required) als auch visuell (z. B. mit Sternchen und erklärendem Text) deutlich zu kennzeichnen. |
|
9.1.1.1 Nicht-Text-Inhalt |
nicht bestanden | Pfeilsymbole, die visuell neue Fenster anzeigen, müssen für Screenreader ausgeblendet werden; die Zusatzinformation „öffnet in neuem Fenster“ sollte über aria-label oder zusätzlichen Text bereitgestellt werden. |
|
9.1.3.2 Bedeutungsvolle Reihenfolge |
nicht bestanden | Jahreszahlen müssen im Quellcode vor dem zugehörigen Textblock stehen (z. B. als Überschrift oder Listenelement), damit Screenreader die chronologische Reihenfolge korrekt ausgeben. |
|
9.1.3.5 Eingabezweck bestimmen |
nicht bestanden | Eingabefelder benötigen das autocomplete-Attribut (z. B. autocomplete="given-name", "email"), damit der Zweck programmatisch übermittelt wird und Autofill/Assistive Technologie korrekt arbeiten. |
|
9.2.4.2 Seite mit Titel |
nicht bestanden | Der HTML-<title> muss sowohl den Unterseitennamen als auch den Websitennamen enthalten (z. B. „Kontakt – Servicestandard“), damit Personen mit mehreren Tabs Orientierung erhalten. |
|
Barrierefreiheitserklärung formal geprüft Barrierefreiheitserklärung formal geprüft |
nicht bestanden | Die Barrierefreiheitserklärung muss klar benannt, leicht erreichbar verlinkt und um Bewertung, nicht barrierefreie Inhalte, Prüfmethode sowie Aktualisierungsdatum ergänzt werden. |
| Kriterium | Status | Notizen |
|---|---|---|
|
9.2.4.7 Fokus sichtbar |
im Wesentlichen bestanden | Der Fokusrahmen darf nicht durch Containerränder oder overflow:hidden abgeschnitten werden, damit Tastaturnutzende stets erkennen, welches Element aktiv ist. |
|
9.1.3.1 Info und Beziehungen |
im Wesentlichen bestanden | Die Überschriftenstruktur soll stufenweise (h1 → h2 → h3) aufgebaut sein, damit die inhaltliche Hierarchie für assistive Technologien nachvollziehbar bleibt. |
|
9.2.4.5 Verschiedene Möglichkeiten |
im Wesentlichen bestanden | Auch wenn aktuell keine Suche existiert, sollte geprüft werden, ob bei Wachstum der Inhalte eine Suchfunktion sinnvoll ergänzt wird sowie Sitemap und Navigation verständlich strukturiert sind. |