ARIA Checker
Prüft robuste HTML- und ARIA-Beziehungen: doppelte IDs, fehlende Referenzziele, unbekannte Rollen, aria-hidden-Fokusfallen und iframes ohne title.
Einen ARIA-Befund an der Komponente nachvollziehen
Beispiel: ein Dialog mit falscher Beschriftung
Ein Dialog verweist mit aria-labelledby auf eine Überschrift. Wird deren ID im Template geändert, kann der Dialog seinen zugänglichen Namen verlieren, obwohl er visuell unverändert aussieht. Suchen Sie deshalb zuerst das referenzierte Element und prüfen Sie, ob die ID genau einmal vorkommt. Wiederholte Dialoge in Produktlisten sind eine typische Stelle für solche Kollisionen.
Nicht nur den Attributwert reparieren
Vergleichen Sie im Accessibility-Baum des Browsers den berechneten Namen mit der sichtbaren Überschrift. Öffnen und schließen Sie den Dialog anschließend per Tastatur. Ein korrektes ARIA-Attribut übernimmt weder die Fokussteuerung noch die Bedienlogik. Der Fokus sollte beim Öffnen sinnvoll im Dialog liegen und nach dem Schließen zur auslösenden Stelle zurückkehren. Dokumentieren Sie den Zustand, in dem der Fehler auftritt; eine Prüfung des geschlossenen Dialogs allein reicht dafür nicht.
Weiterführende Dokumentation: W3C: modale Dialoge
ARIA und Robustheit
Fokussierte Ansicht für HTML-Robustheit sowie Namen, Rollen und Werte nach WCAG 4.1.2.
Barrierefreiheit und weitere Prüfbereiche gemeinsam analysieren: bis zu 20 URLs kostenlos. Vollständiges Website-Audit für einmalig 69 € netto oder SEO Suite ab 29 € netto monatlich.
ARIA soll helfen, nicht kaschieren
ARIA ist sinnvoll, wenn native HTML-Semantik nicht ausreicht. Fehlerhafte Rollen oder kaputte ID-Beziehungen können assistive Technologien aber stärker verwirren als fehlendes ARIA.
Priorisierte Checks
- Doppelte IDs, die Labels und ARIA-Beziehungen brechen.
- aria-labelledby, aria-describedby oder aria-controls ohne Ziel.
- Unbekannte role-Werte.
- Fokussierbare Elemente in aria-hidden-Bereichen.
ARIA-Probleme mit Augenmaß beheben
ARIA ist kein Ersatz für sauberes HTML. Die wichtigsten Findings sind solche, die Namen, Rollen oder Zustände falsch an assistive Technologien melden. Wenn ein Button, Dialog oder Tab-System dadurch anders erscheint als es visuell funktioniert, entsteht ein echtes Nutzungsproblem.
Priorisierung in der Praxis
- Fehlende Ziele von aria-labelledby, aria-describedby und aria-controls beheben
- Doppelte IDs in Templates bereinigen, bevor Komponenten wiederverwendet werden
- Fokussierbare Elemente in aria-hidden-Bereichen aus dem Tabfluss entfernen
Nächster sinnvoller Check
Nach den technischen Korrekturen sollten interaktive Komponenten zusätzlich per Tastatur und Screenreader geprüft werden.
Wann ARIA-Befunde kritisch sind
Besonders wichtig sind Komponenten, die Zustände ändern: Menüs, Dialoge, Tabs, Accordions, Filter und Formularmeldungen. Wenn ARIA dort falsche Namen, Rollen oder Beziehungen meldet, entsteht ein Widerspruch zwischen sichtbarer Bedienung und assistiver Ausgabe.
Bei wiederverwendeten Komponenten lohnt sich die Korrektur im Template. Ein einzelner Fehler in Navigation oder Modal kann sonst auf vielen URLs gleichzeitig auftreten.
Ein guter Review trennt deshalb echte Bedienfehler von rein kosmetischen Warnungen. Wenn ein Befund Name, Rolle, Zustand oder Fokus betrifft, gehört er in die technische Prioritätenliste; reine Redundanz kann später bereinigt werden.