“Ich mach mal schnell ARIA drauf, dann ist’s barrierefrei”
Spoiler: Nein, ist es nicht.
Kaum etwas triggert mich in Code-Reviews so sehr wie sinnloses ARIA. Das Schlimme? Ich war früher genauso. Mehr ARIA = mehr Barrierefreiheit, dachte ich. Wie ein Hobby-Koch, der glaubt, mehr Gewürze machen automatisch besseres Essen.
Das Ergebnis? Websites, die für blinde Nutzer ein absolutes Chaos waren. Screen-Reader, die wirres Zeug vorlasen. Buttons, die keine waren. Ein digitales Minenfeld.
Die unbequeme Wahrheit
WebAIM untersucht jedes Jahr eine Million Websites auf Barrierefreiheit. 2024 war das Ergebnis eindeutig: Websites MIT ARIA hatten 70% mehr Fehler als ohne.
Lass dir das auf der Zunge zergehen.
Das Tool für Barrierefreiheit macht Websites im Durchschnitt schlechter.
Nicht weil ARIA schlecht ist. Sondern weil wir es falsch einsetzen.
HTML kann mehr als du denkst
Stell dir vor: Du willst einen Button bauen. Einen simplen Knopf zum Klicken.
Option A: Ein <div> mit role="button", tabindex="0" für Fokus, Click-Handler, Keypress-Handler für Tastatur, CSS zum Stylen…
Option B: <button>.
Fertig. Drei Sekunden. Funktioniert. Ist barrierefrei.
Warum macht man Option A?
“Aber mein Designer will es so!”
Dann hat dein Designer CSS nicht entdeckt. Ein <button> kann aussehen wie alles.
“Aber das Framework macht das so!”
Dann ist dein Framework Müll. Sorry, not sorry.
Wann ARIA wirklich Sinn macht
Jetzt wo ich mich ausgetobt habe: Es gibt legitime Gründe für ARIA.
Live-Updates: Ein Chat bekommt eine neue Nachricht. Der Screen-Reader merkt nichts, weil sich nur das DOM ändert. Hier hilft role="alert" mit aria-live="polite" - der Screen-Reader liest die Nachricht vor.
Komplexe Widgets: Tabs, Accordions, komplexe Dropdowns. Manchmal brauchst du sie wirklich. Aber frag dich IMMER zuerst: Brauche ich das? Tabs können oft einfach Überschriften sein. Viel simpler. Kein JavaScript. Kein ARIA.
Fortschrittsanzeigen: Ladebalken, Upload-Progress. Hier gibt’s kein natives HTML. role="progressbar" ist legitim.
Das ist der Sweet Spot: Dinge zugänglich machen, die HTML allein nicht kann.
Die ARIA-Fallen
Die Button-Lüge
Ein <div> mit role="button". Der Screen-Reader sagt “Button”. Der Nutzer drückt Enter. Nichts passiert.
Warum? Ein <div> hat kein Button-Verhalten. Du hast gelogen.
Das ist wie ein “Toilette”-Schild an einer verschlossenen Tür. Technisch korrekt beschriftet. Praktisch nutzlos. Und verdammt frustrierend.
ARIA-Label-Wahnsinn
Neulich gesehen: aria-label="Klicken Sie hier um das Formular zu öffnen mit dem Sie uns eine Nachricht senden können und wir werden uns dann bei Ihnen melden innerhalb von 24 Stunden"
Sichtbarer Text? “Kontakt”
Der Screen-Reader liest den ganzen Roman vor. Bei jedem Fokus. Stell dir vor, du navigierst mit Tab und musst bei jedem Button einen Aufsatz hören.
Die Lösung: Mach den sichtbaren Text aussagekräftig. Dann brauchst du kein aria-label.
Redundantes ARIA
Ein <button> mit role="button". Ein <nav> mit role="navigation".
Das ist “RIP in peace”. Macht keinen Sinn, sieht man trotzdem überall.
Warum? Entwickler haben Angst, nicht genug zu tun. Also kommt ARIA drauf. Zur Sicherheit.
Es macht die Sache nicht sicherer. Nur lauter für Screen-Reader.
Als ich kürzlich eine Vue/Quasar-App barrierefrei machen musste
Kunde meint: “Wir haben da eine ältere Bank-App. Vue und Quasar Framework. Läuft super. Nur… nicht barrierefrei. Kannst du das bis zum Stichtag fixen?”
Code aufgemacht. Quasar überall. <q-btn>, <q-input>, <q-dialog>, <q-menu>.
Das Problem? Die App wurde vor etwa 5 Jahren entwickelt. Damals war Barrierefreiheit in Component-Frameworks noch ein Nachgedanke. Die Components nutzten nicht die richtigen HTML-Elemente. Stattdessen: Div-Suppe mit Event-Handlern - war früher eher normal.
Zwei Optionen:
- App neu schreiben mit nativen Elementen
- ARIA-Pflaster überall drauf
Kunde: “Kannst du das in 2 Wochen fixen?”
Also Option 2. ARIA überall. role="button", aria-label, aria-expanded, aria-controls, aria-describedby - das volle Programm.
Und es hat funktioniert. Die App wurde barrierefrei. WCAG 2.2 AA. Grüne Häkchen.
Aber es war eigentlich die falsche Lösung.
Warum? Weil ich jetzt eine App hatte auf einer Schicht Komponenten, die auf ARIA saß, das HTML simuliert.
Jedes Quasar-Update? Risiko, dass ARIA kaputtgeht. Jede neue Funktion? Erstmal überlegen: Welches ARIA brauche ich?
Die harte Lektion: ARIA kann ein Pflaster sein. Aber ein Pflaster heilt keine chronische Krankheit. Es verdeckt nur Symptome.
Heute würde ich Native HTML nutzen und nur bei wirklich komplexen Dingen auf Framework-Components setzen. Weniger Abhängigkeiten. Weniger ARIA. Mehr Kontrolle.
Was ich gelernt habe
ARIA ist wie scharfe Gewürze. Ein bisschen zur richtigen Zeit? Perfekt. Zu viel oder falsch? Verdorben.
Die beste Barrierefreiheit kommt nicht durch mehr ARIA, sondern durch:
Sauberes, semantisches HTML. Nicht sexy, aber funktioniert.
Logische Struktur. Überschriften, die Sinn machen. Landmarks, die helfen.
Aussagekräftiger sichtbarer Text. Nicht “Mehr erfahren”, sondern “Mehr über unsere Services”.
Tastatur-Navigation. Alles muss mit Tab und Enter funktionieren.
Und dann – DANN – kommt ARIA. Als chirurgisch präzises Werkzeug für die wenigen Stellen, wo HTML nicht reicht.
Der Realitätscheck
Das klingt alles sehr schwarz-weiß. Aber die Realität ist komplizierter.
React-Shop mit dynamischen Filtern? Da brauchst du aria-live.
Dashboard mit komplexen Interaktionen? Da wirst du um ARIA nicht rumkommen.
Aber diese Fälle sind die Ausnahme, nicht die Regel.
Die meisten Websites brauchen 95% weniger ARIA als sie haben.
Meine persönliche ARIA-Regel
Wenn ich ARIA einsetzen will, schlafe ich eine Nacht drüber.
Am nächsten Tag frage ich mich:
- Kann ich das mit nativem HTML lösen?
- Kann ich die Struktur so ändern, dass ich kein ARIA brauche?
- Habe ich wirklich alle Optionen ausgeschöpft?
In 80% der Fälle: “Ja, geht auch ohne. Und ist sogar besser.”
Der Appell
Bevor du das nächste Mal ARIA einsetzt: Halt inne. Atme durch.
“Würde ein blinder Entwickler meinen Code verfluchen?”
Wenn die Antwort “Ja” oder “Vielleicht” ist: Lass es. Such nach HTML.
Und wenn du ARIA einsetzt: Test es. Mit einem echten Screen-Reader. NVDA ist kostenlos. Keine Ausreden.
Barrierefreiheit ist kein Checkbox-Spiel. Nicht “ARIA drauf = fertig”. Es ist die Kunst, Dinge so einfach und klar zu machen, dass jeder sie nutzen kann.
Auch ohne 17 ARIA-Attribute.
PS: Wenn du jemanden siehst, der ein <div> mit role="button" baut, obwohl ein <button> funktioniert: Schick ihm diesen Artikel. Oder eine Tastatur. Oder beides.
Kommentare