Name, Rolle, Wert und Statusmeldungen: was Hilfsmittel aus dem Code lesen
Jedes Bedienelement muss für Hilfsmittel erkennbar machen, wie es heißt, was es ist und in welchem Zustand es sich befindet. Und Meldungen, die ohne Seitenwechsel erscheinen — „gespeichert", „3 Treffer", „Fehler" —, müssen angesagt werden, ohne den Fokus zu verschieben.
Was dazu geprüft wird
2 Prüfpunkte aus dem WCAG 2.2, Leitlinie 4.1 — die Liste stammt aus dem Messkern, nicht aus diesem Text.
- 4.1.2 Name, Rolle, Wert · Stufe A
- 4.1.3 Statusmeldungen · Stufe AA
Jeder dieser Punkte steht mit Erklärung in der vollständigen Prüfpunktliste.
Worauf es in der Praxis ankommt
Wer Standardelemente benutzt, erfüllt das meiste von selbst: Ein <button> meldet Rolle und Zustand ohne Zutun. Probleme entstehen bei nachgebauten Elementen — ein <div> mit Klick-Ereignis hat keine Rolle, keinen Namen und keinen Zustand.
ARIA ist dabei Werkzeug und Fehlerquelle zugleich: Falsch gesetzte Attribute machen die Lage schlechter als gar keine. Ein aria-expanded, das nicht mit dem tatsächlichen Zustand mitläuft, sagt dem Nutzer aktiv etwas Falsches.
Statusmeldungen sind der häufigste Fall bei Suchfeldern mit Sofortergebnis: Die Trefferzahl ändert sich sichtbar, wird aber nie angesagt. Wer nicht sieht, erfährt nichts davon.
Häufige Fragen
Ist ARIA immer besser als reines HTML?
Im Gegenteil. Standardelemente bringen Rolle, Name und Zustand mit; ARIA sollte nur ergänzen, was HTML nicht ausdrücken kann. Falsches ARIA richtet mehr Schaden an als gar keines.
Was ist eine Statusmeldung?
Eine Rückmeldung, die ohne Seitenwechsel erscheint und nicht den Fokus bekommt: Trefferzahlen, Speicherbestätigungen, Ladehinweise, Fehlerzusammenfassungen.
Warum meldet die Prüfung Fehler, obwohl die Seite bedienbar aussieht?
Weil „sieht bedienbar aus" und „ist maschinenlesbar" zwei verschiedene Dinge sind. Ein nachgebautes Bedienelement funktioniert mit der Maus einwandfrei und ist für einen Screenreader trotzdem nur ein Textblock.
Weitere Themen aus Barrierefreiheit
- Alternativtexte prüfen: wann ein Bild einen Text braucht
- Untertitel und Audiodeskription: was bei Video und Audio verlangt wird
- Struktur und Lesereihenfolge: warum Aussehen und Code übereinstimmen müssen
- Farbkontraste prüfen: 4,5:1, 3:1 und was sonst noch zählt
- Tastaturbedienung prüfen: alles erreichbar, nichts gefangen
- Zeitbegrenzungen und bewegte Inhalte: Kontrolle beim Nutzer
- Blitzende Inhalte: die Grenze von dreimal pro Sekunde
- Navigation und Fokus: sichtbar, auffindbar, in sinnvoller Reihenfolge
- Zielgrößen und Zeigereingaben: 24×24 Pixel und was daran hängt
- Sprachauszeichnung prüfen: lang-Attribut richtig setzen
- Vorhersehbarkeit: keine Überraschungen bei Fokus und Eingabe
- Formulare und Fehlermeldungen: erkennen, erklären, vermeiden