Barrierefreiheit ist kein letzter QA-Schritt

Barrierefreiheit wird in Webprojekten noch immer häufig behandelt wie ein abschließender Qualitätstest:

Die Seite ist fertig, das Design steht, die Komponenten funktionieren – und dann schaut jemand, ob Kontraste passen, Alt-Texte vorhanden sind und man alles mit der Tastatur bedienen kann. Technisch funktioniert das natürlich irgendwie. Sinnvoll ist es aber nicht.

Die W3C Web Accessibility Initiative empfiehlt ausdrücklich, Accessibility von Anfang an in Projekte einzubauen. Das ist nicht nur effektiver, sondern verhindert auch, dass später bereits fertige Strukturen wieder umgebaut werden müssen.

Accessibility beginnt bei Architektur und Komponenten

Viele Probleme entstehen nicht durch einen einzelnen fehlenden aria-label. Sie entstehen viel früher. Zum Beispiel bei der Frage:

• Ist ein Element überhaupt ein Button oder nur ein klickbares div?
• Ist eine Komponente per Tastatur vollständig bedienbar?
• Ist die Reihenfolge der Inhalte auch ohne visuelles Layout verständlich?
• Können Formulare verständliche Fehlerzustände kommunizieren?
• Funktioniert eine Navigation auch ohne Maus?
• Welche Verantwortung liegt beim CMS und welche beim Frontend?

Das sind Architektur- und Komponentenentscheidungen. Wenn eine Basis-Komponente falsch aufgebaut ist und auf einer Website 40-mal verwendet wird, hat man nicht 40 kleine Accessibility-Probleme. Man hat ein strukturelles Problem.

Semantisches HTML löst erstaunlich viel

Ich versuche deshalb zuerst zu überlegen, welches HTML-Element tatsächlich zur Aufgabe passt.

Ein Button ist ein <button>.

Eine Navigation ist eine <nav>.

Überschriften bilden eine sinnvolle Hierarchie.

Formularfelder haben Labels.

Das klingt banal, verhindert aber viele Probleme, bevor zusätzliche ARIA-Attribute oder JavaScript überhaupt notwendig werden.

Accessibility ist für mich deshalb oft weniger die Frage:

„Was müssen wir noch hinzufügen?“

und mehr:

„Haben wir die Basis richtig gebaut?“

Tastaturbedienung ist ein guter Realitätstest

Einer meiner einfachsten Tests ist: Maus weglegen. Kann ich die Seite vollständig benutzen?

Die W3C nennt Tastaturzugänglichkeit als grundlegendes Beispiel: Eine barrierefreie Website darf nicht davon abhängig sein, dass ein Nutzer eine Maus verwenden kann. Dabei entdeckt man ziemlich schnell Probleme:

• Fokus ist nicht sichtbar
• Elemente sind nicht erreichbar
• Modals halten den Fokus nicht sinnvoll
• Menüs funktionieren nur mit Hover
• die Fokusreihenfolge ergibt keinen Sinn

Und viele dieser Probleme betreffen nicht ausschließlich Menschen mit dauerhaften Einschränkungen.

Accessibility hilft beispielsweise auch Nutzern mit temporären oder situativen Einschränkungen – etwa einem gebrochenen Arm, hellem Sonnenlicht oder einer Umgebung, in der Audio nicht genutzt werden kann.

Automatische Tests sind hilfreich – aber nicht genug

Tools wie Lighthouse, axe oder automatisierte CI-Checks sind sehr nützlich. Ich würde sie immer einsetzen. Aber sie können nur einen Teil der Probleme erkennen.

Auch die W3C weist ausdrücklich darauf hin, dass kein automatisches Tool allein feststellen kann, ob eine Website tatsächlich alle Accessibility-Anforderungen erfüllt. Dafür ist weiterhin eine fachkundige menschliche Bewertung notwendig.

Ein Tool kann zum Beispiel feststellen, dass ein Bild ein alt-Attribut besitzt. Es kann aber deutlich schlechter beurteilen, ob der darin enthaltene Text in diesem konkreten Kontext überhaupt sinnvoll ist.

Deshalb sehe ich Accessibility-Testing eher als Kombination aus:

Automatisierung + manuellen Tests + technischem Verständnis.

Accessibility ist für mich Teil von Softwarequalität

Ich finde es deshalb wenig sinnvoll, Barrierefreiheit als separates Spezialthema zu betrachten, das irgendwann am Ende eines Projekts auftaucht. Sie hängt direkt mit Dingen zusammen, die ohnehin gute Software ausmachen:

• saubere Komponenten
• verständliche Strukturen
• robuste Interaktionen
• klare Zustände
• gute Bedienbarkeit
• Wartbarkeit
• Tests

Die W3C formuliert Web Accessibility grundsätzlich als Voraussetzung dafür, dass Menschen Websites und Webanwendungen wahrnehmen, verstehen, navigieren und bedienen können.

Für mich bedeutet das in der Entwicklung: Barrierefreiheit sollte nicht die Frage sein, die wir kurz vor dem Release stellen. Sie sollte eine der Fragen sein, die wir stellen, bevor wir eine Komponente überhaupt bauen.