More is less: Wenn zu viel Barrierefreiheit Barrieren schafft

---

Wer sich länger mit digitaler Barrierefreiheit beschäftigt, stößt früher oder später auf einen Satz, der in der Accessibility-Community fast schon ein geflügeltes Wort geworden ist:

„No ARIA is better than bad ARIA.“

Der Satz stammt aus den WAI-ARIA Authoring Practices und bringt ein Problem auf den Punkt, das ich in Audits regelmäßig sehe: Gute Absichten führen nicht automatisch zu besseren Ergebnissen.

Im Gegenteil. Oft wird Barrierefreiheit durch zusätzliche Attribute, Skripte oder vermeintliche Optimierungen sogar schlechter.

Mehr Accessibility-Code bedeutet nicht mehr Barrierefreiheit

Viele Entwicklerinnen und Entwickler lernen irgendwann, dass es Attribute wie aria-label, aria-hidden, role oder aria-describedby gibt. Das ist grundsätzlich gut. Problematisch wird es, wenn diese Werkzeuge ohne Verständnis eingesetzt werden.

ARIA ist kein Zauberpulver, das man über eine Website streut und danach ist alles barrierefrei.

Die meisten nativen HTML-Elemente bringen bereits eine eigene Semantik und Zugänglichkeit mit. Ein Button ist ein Button. Ein Link ist ein Link. Eine Überschrift ist eine Überschrift.

Sobald zusätzliche ARIA-Attribute ins Spiel kommen, greifen diese direkt in die Accessibility APIs von Browsern, Betriebssystemen und Hilfstechnologien ein. Fehler wirken sich dadurch unmittelbar auf die Nutzerinnen und Nutzer aus.

Mein Lieblingsbeispiel: Das Logo namens „favicon“

Ein Fall aus einem echten Projekt ist mir bis heute in Erinnerung geblieben.

Auf der Website war das Logo korrekt umgesetzt. Das Bild besaß einen sinnvollen Alternativtext. Der Link führte auf die Startseite.

Eigentlich alles richtig.

Irgendwann wurde zusätzlich ein aria-label ergänzt:

<a href="/" aria-label="favicon">
    <img src="/logo.svg" alt="Unternehmensname" />
</a>

Für Screenreader-Nutzende war das Ergebnis ernüchternd.

Statt den Unternehmensnamen anzukündigen, wurde nun lediglich „favicon“ vorgelesen.

Der Grund ist simpel: Das aria-label überschreibt den zugänglichen Namen, der ansonsten aus dem Bild und seinem Alternativtext ermittelt worden wäre.

Die Accessibility wurde nicht verbessert. Sie wurde zerstört.

Die korrekte Lösung wäre schlicht gewesen:

<a href="/">
    <img src="/logo.svg" alt="Unternehmensname" />
</a>

Wenn Hilfetexte zum Roman werden

Ein weiteres Muster begegnet mir regelmäßig in Formularen.

Labels sind vorhanden, Eingabefelder ebenfalls. Eigentlich funktioniert alles.

Dann werden zusätzliche ARIA-Attribute ergänzt, weitere Hinweise verknüpft und jede denkbare Information in die Ausgabe des Screenreaders gepackt.

<input
    id="firstname"
    aria-label="Vorname"
    aria-describedby="
        help-1
        help-2
        help-3
        help-4
    "
/>

Das Ergebnis klingt dann ungefähr so:

Vorname, Pflichtfeld, Bitte geben Sie Ihren Vornamen ein, dieses Feld darf nicht leer sein, alle Felder mit Sternchen sind Pflichtfelder, weitere Informationen finden Sie …

Technisch mag das korrekt sein.

Praktisch wird das Formular dadurch langsamer, anstrengender und schwerer bedienbar.

Barrierefreiheit bedeutet nicht, möglichst viele Informationen anzusagen. Barrierefreiheit bedeutet, die richtigen Informationen zum richtigen Zeitpunkt bereitzustellen.

Oft reicht bereits sauberes HTML:

<label for="firstname"> Vorname </label>

<input id="firstname" name="firstname" required />

Der Drang, HTML neu zu erfinden

Besonders kritisch wird es, wenn ARIA eingesetzt wird, um vorhandene HTML-Funktionen nachzubauen.

Ich sehe regelmäßig Konstruktionen wie diese:

<div role="button" tabindex="0">Absenden</div>

Der Gedanke dahinter ist nachvollziehbar. Man möchte einen Button erzeugen.

Tatsächlich erhält man aber nur einen kleinen Teil dessen, was ein echter Button automatisch mitbringt.

Tastaturbedienung, Fokusverhalten, Zustände und Browserunterstützung müssen anschließend mühsam nachgebaut werden.

Der native Button hätte all das bereits kostenlos geliefert:

<button type="submit">Absenden</button>

Wenn Accessibility Overengineering wird

Ein weiteres Problem entsteht häufig durch Checklisten, automatische Prüfwerkzeuge oder den Druck, möglichst viele Accessibility-Maßnahmen vorweisen zu können.

Dann werden überall zusätzliche Labels ergänzt. Jedes Element bekommt ARIA-Attribute. Komponenten werden mit mehreren Rollen, Zuständen und Beschreibungen versehen.

Die Website wirkt dadurch auf den ersten Blick „barrierefreier“, weil mehr Accessibility-Code vorhanden ist.

In Wirklichkeit steigt aber oft nur die Komplexität.

Gerade Menschen, die Screenreader nutzen, profitieren von klaren, konsistenten und vorhersehbaren Oberflächen. Jedes zusätzliche Attribut erhöht die Wahrscheinlichkeit für Fehler, Widersprüche oder unerwartetes Verhalten.

Die eigentliche Aufgabe

Eine der wichtigsten Lektionen aus über zehn Jahren Frontend-Entwicklung und Barrierefreiheit lautet:

Barrierefreiheit entsteht selten durch zusätzliche Technik.

Sie entsteht durch gutes HTML, sinnvolle Strukturen, verständliche Inhalte und eine saubere Umsetzung.

ARIA ist ein mächtiges Werkzeug. Aber wie jedes mächtige Werkzeug kann es Schaden anrichten, wenn es falsch eingesetzt wird.

Deshalb gilt bis heute:

No ARIA is better than bad ARIA.

Und manchmal besteht die beste Accessibility-Maßnahme nicht darin, ein weiteres Attribut hinzuzufügen, sondern eines wieder zu entfernen.