Barrierefreiheitstesten bedeutet, digitale Anwendungen durch betroffene Personen mit Screenreader und Braillezeile auf echte Nutzbarkeit zu prüfen. Automatisierte Tests erkennen fehlende HTML-Attribute, können aber nicht beurteilen, ob Bedienelemente semantisch sinnvoll eingesetzt sind. Gute Barrierefreiheit und gute Frontend-Architektur korrelieren dabei direkt.
Das Wichtigste in Kürze
- Schlechte Barrierefreiheit ist ein direkter Indikator für schlechte Frontend-Architektur: Wer gute Patterns und saubere HTML-Strukturen verwendet, erfüllt Barrierefreiheitsanforderungen oft automatisch mit.
- Screenreader wie JAWS erlauben es, nicht barrierefreie Desktop-Anwendungen durch pixelbasierte Skripte nutzbar zu machen, was jedoch bedeutet, dass jede Änderung an Fenstergröße oder Auflösung die Funktion sofort brechen kann.
- Barrierefreie Komponenten im Styleguide garantieren keine barrierefreie Anwendung, weil die Kombination mehrerer Komponenten oder eine abweichende Umsetzung die Zugänglichkeit trotzdem zerstören kann.
- Testautomatisierung kann prüfen, ob eine ARIA-Role gesetzt ist, aber nicht, ob das semantische Element für den jeweiligen Zweck überhaupt logisch ist. Dieser Urteilsschritt bleibt manuellen Tests vorbehalten.
Was Barrierefreiheitstests von normalen Tests unterscheidet
Barrierefreiheitstests prüfen, ob eine Anwendung auch ohne visuelle Wahrnehmung nutzbar ist, und sie lassen sich nicht vollständig automatisieren. Ein Werkzeug kann erkennen, ob die Rolle eines Bedienelements im HTML gesetzt ist. Ob diese Rolle für ihren Zweck logisch ist, sagt es nicht.
Genau hier setzt der manuelle Test durch betroffene Nutzer an. Serdal Bilir arbeitet als Barrierefreiheitstester und Berater, ist selbst gesetzlich blind und prüft Anwendungen mit denselben Hilfsmitteln, die auch im Alltag zum Einsatz kommen: einem Screenreader und einer Braillezeile, die den Bildschirminhalt mit den Fingern lesbar macht.
Der Vorteil dieser Konstellation liegt in der Erfahrung. Wer eine Anwendung täglich mit einem Screenreader bedient, weiß sofort, ob ein Ablauf trägt oder bricht. Serdal arbeitet bei seinen Entwicklungsbegleitenden Tests nicht mehr strikt nach vorgegebenen Testfällen, sondern geht die Anwendung nach Erfahrung durch und deckt darüber das Wesentliche ab.
Warum semantische Elemente über den Erfolg entscheiden
Ein Bedienelement muss das tun, was es vorgibt zu sein. Eine Registerkarte signalisiert dem Screenreader-Nutzer, dass sich der Inhalt wechselt. Wird eine Registerkarte aber technisch eingesetzt, um zu einer Sprungmarke zu springen, entsteht ein Widerspruch zwischen Ankündigung und Verhalten.
Serdal beschreibt einen solchen Fall: Ein Abfrageformular nutzte Registerkarten für Sprungmarken. Im HTML war ein Skip-Link verbaut, der nach außen als Registerkarte ausgegeben wurde. Für sehende Nutzer fällt das nicht auf. Für jemanden, der die Ausgabe hört oder ertastet, kollidiert die Erwartung mit der Realität.
Die Regel dahinter ist einfach: semantische Elemente verwenden, die ihre Funktion korrekt benennen. Keine Fake-Elemente, die optisch passen, aber falsch deklariert sind. Diese Disziplin ist die Grundlage dafür, dass ein Screenreader eine Oberfläche überhaupt sinnvoll vermitteln kann.
Gute Architektur und gute Barrierefreiheit hängen zusammen
Eine saubere Frontend-Entwicklung und eine funktionierende Barrierefreiheit korrelieren stark. Wer gute Muster verwendet, hat eine hohe Chance, ohne Zusatzaufwand barrierefrei zu sein. Umgekehrt ist eine schlecht zugängliche Anwendung ein Indikator dafür, wie im Frontend gearbeitet wurde.
Das Prinzip reicht zurück bis zur Trennung von Inhalt und Form über CSS und HTML und zieht sich durch bis zur Strukturierung der Oberfläche. Die nicht sichtbare Gruppierung von Elementen ist selbst ein Architekturbestandteil. Wer diese Struktur weglässt, liefert den Inhalt als reinen Text aus, und Nutzer, die auf diese Struktur angewiesen sind, kommen damit nicht zurecht.
René Matthäi zieht die Parallele zur Testautomatisierung. Sich selbst auszeichnende Bedienelemente, die erkennen lassen, was sie sind und was sie können, helfen nicht nur Screenreadern, sondern jeder Form der Automatisierung. Dieselbe Anforderung, die einen Test robust macht, macht eine Anwendung zugänglich.
Wenn eine Anwendung extrem schlecht barrierefrei ist, dann ist das definitiv ein Indikator dafür, wie in der Frontendentwicklung vorgegangen wurde. René Matthäi
Wie sich Entwickler in eine Sehbehinderung hineinversetzen
Der schnellste Weg zum Verständnis ist die direkte Demonstration. Serdal lädt Entwickler in sein Büro ein und zeigt ihnen seine Braillezeile, auf der sich Bildschirminhalt als Brailleschrift abbilden lässt. Zusätzlich schaltet er im Screenreader den Sprach- und Braillebetrachter zu, ein Onboard-Mittel, das sehenden Kollegen in einer Leiste anzeigt, was er gerade hört und ertastet.
Ist ein Treffen vor Ort nicht möglich, teilt er in einem Online-Meeting seinen Sound, sodass die Beteiligten den Screenreader mithören. In beiden Fällen kippt das Verständnis an derselben Stelle: Sobald jemand das Problem hört, wird es greifbar.
Wer das selbst ausprobieren will, braucht dafür keine kostenpflichtige Software. Neben dem kommerziellen JAWS gibt es NVDA, einen Open-Source-Screenreader, dessen Name für Non-Visual Desktop Access steht. Er lässt sich herunterladen und für eigene Tests einsetzen.
Warum frühe Einbindung das größte Projektproblem bleibt
Die zwei größten Hürden sind verspätete Einbindung und fehlende Grundkenntnisse im Team. Barrierefreiheit taucht in der Projektcheckliste auf, doch in der Praxis kommt der Kontakt oft erst kurz vor dem Go-Live zustande, wenn die Abnahme ansteht.
Sinnvoller ist ein vereinbarter Arbeitsmodus mit festen Wiedersehenspunkten über das Projekt hinweg. Dazu gehört das gemeinsame Verständnis, welche Testschritte durchgeführt werden, welche Werkzeuge zum Einsatz kommen und wie der HTML-Code beschaffen sein muss. Eine Grundahnung ist meist da. Beim Durchgehen der Anwendung tauchen trotzdem regelmäßig Aha-Momente auf.
Ein verbreiteter Trugschluss betrifft fertige Komponenten. Wenn ein Styleguide-Team Eingabefelder, Tabellen und Buttons als barrierefreie Bausteine liefert, erwarten Projektleiter und Entwickler, dass das Ergebnis automatisch barrierefrei ist. Das gilt nur in der Theorie. Werden Komponenten nicht exakt wie vorgesehen umgesetzt, oder kommen mehrere zusammen, kann die Barrierefreiheit trotzdem brechen.
Der dritte Beteiligte: warum Tester und Entwickler nicht genügen
Für gute Barrierefreiheit reicht das Duo aus Tester und Entwickler nicht aus, es fehlt eine Rolle für das UI-Design. René beschreibt ein Projekt, in dem eng und fokussiert zusammengearbeitet wurde. Dabei wurden an anderer Stelle Dinge verschlimmbessert, die nur auffielen, weil ein zweiter Tester auch die sehenden Testschritte mit prüfte.
Daraus folgt der Bedarf nach einer Person, die das Frontend wie ein Business Analyst betrachtet: Wie soll ein Element sein, und wie ist es an vergleichbaren Stellen der Anwendung gelöst? Ohne diese Klammer laufen Entscheidungen auseinander.
Die direkte Zusammenarbeit zwischen Tester und Entwickler bleibt trotzdem wichtig. Ein Entwickler muss bei den Tests dabei sein, weil nur er versteht, was technisch gebraucht wird. Es hat lange gedauert, diese Präsenz durchzusetzen. Befunde werden direkt notiert und weitergegeben, statt über Umwege zu verschwinden.
Wie sich Befunde ohne Quellcode-Lesen reporten lassen
Serdal prüft Bedienelemente über die HTML-Schnittstelle, ohne den gesamten Quellcode öffnen zu müssen. Liest der Screenreader bei einem Button nur “Schalter” vor, statt dessen Inhalt zu nennen, fokussiert er das Element und ruft per Tastenkombination die HTML-Informationen ab.
Dort sieht er Rolle und Tag und erkennt, ob das Element ein Label trägt. Fehlt das Label-Tag, benennt er den konkreten Befund, und die Entwicklung trägt es nach. Das ist gezielter als der Blick in den vollständigen Quellcode, weil direkt das betroffene Element untersucht wird.
Web-Anwendungen sind dabei deutlich leichter zugänglich als Desktop-Anwendungen. Selbst Office-Produkte sind nicht von Haus aus barrierefrei. Dass sie sich nutzen lassen, liegt an Skripten und Adaptationen, die der Screenreader-Hersteller mitliefert. Im Alltag merkt man das nicht, im Hintergrund läuft jedoch eine zusätzliche Schicht.
Wie alte Desktop-Anwendungen trotzdem nutzbar werden
Eine über 20 Jahre gewachsene Desktop-Anwendung lässt sich auch dann zugänglich machen, wenn sie von Grund auf nicht barrierefrei ist. Eine solche Anwendung bildet das Hauptgeschäft im Amt ab, wurde bei jedem Windows-Wechsel mit hochgezogen und lässt sich teils nicht einmal per Tastatur bedienen.
Die Lösung sind Skripte, die JAWS auf die Anwendung adaptieren. Man legt dem Screenreader eine Art Schablone über die Oberfläche und teilt ihm mit, wo welcher Button liegt. Das funktioniert über Pixelangaben, im Kern werden die Grafikkartentreiber abgegriffen, also das, was die Grafikkarte gerade liefert.
Dieser Pixelbezug ist fragil. Verändert sich die Fenstergröße, stimmen die Koordinaten nicht mehr, und betroffene Kollegen melden, dass etwas nicht mehr geht. Oft hilft schon das Maximieren des Fensters. Robuster ist die Alternative, dem Screenreader statt Pixeln einen Anker zu nennen, etwa einen Button mit bestimmter Farbe, Schattierung und Inhalt.
Die Entwicklung erinnert an die der Testautomatisierung, die früher ebenfalls auf Koordinaten setzte, bevor die Objekterkennung kam. Wer in Barrierefreiheit investiert, verbessert damit auch die Voraussetzungen für robuste Testautomatisierung, und umgekehrt.
Zwei Wege gleichzeitig: Anwendung stärken und Assistenz verbessern
Barrierefreiheit braucht eine parallele Strategie. Auf der einen Seite muss die Nutzung tatsächlich funktionieren, auf der anderen Seite muss die Web-Anwendung von sich aus möglichst viel mitbringen, statt sich auf vorgeschaltete Assistenz zu verlassen.
In der Internetwelt wird über Overlays diskutiert, also vorgeschaltete Assistenzfunktionen, die bestehende Angebote besser benutzbar machen sollen, ähnlich wie ein Screenreader. Verlagert man die Verantwortung allein dorthin, entstehen zwei Probleme: Der Screenreader bekommt mehr Schwierigkeiten als nötig, und nicht jeder Nutzer hat ein solches Hilfsmittel zur Hand oder kann es sich leisten.
Daraus folgt das Prinzip Shift Left. Je mehr eine Anwendung an Zugänglichkeit von vornherein mitbringt, desto weniger muss die Assistenzschicht ausgleichen. Self-Service und Schulung gehören dazu, denn wer eine Anwendung nicht selbst bedienen kann, behilft sich mit Workarounds. Manche Buttons reagieren weder auf Enter noch auf die Leertaste, dann lässt sich der Screenreader anweisen, die Maus zum Tastaturfokus zu ziehen und einen Klick zu simulieren. Solche Kniffe kennt nur, wer sie gelernt hat.
Wo gute Quellen den Einstieg leicht machen
Barrierefreiheit ist ein Thema mit ungewöhnlich guter Dokumentation. Die Web Content Accessibility Guidelines sind für Entwickler prägnant aufbereitet, man muss sie im Grunde nur lesen und sich durch die Quellen bewegen.
Für Unternehmen wird das Thema dringlicher, weil gesetzliche Vorgaben es vom Sonderfall zum Standard machen. Diese Pflicht ist eine der tragenden Säulen, auch wenn niemand gern die gesetzliche Keule schwingt. Sie verschafft dem Thema Aufmerksamkeit, die es vorher nicht hatte.
Für die Projektarbeit bleiben drei Hebel zentral: Wiederverwendbarkeit von Komponenten, ein einheitliches Look and Feel über Anwendungen hinweg und eine engere, frühere Zusammenarbeit. Je konsistenter Anwendungen aufgebaut sind, desto weniger Reibung entsteht für die Menschen, die sie ohne visuelle Wahrnehmung bedienen.
