FH-Prof. DI Dr. techn. Robert Pucher beschreibt in seinem Artikel „Usability-Tests, GenAI und der Schritt dazwischen“ bereits ausführlich die Schwierigkeit, Bedienbarkeit systematisch zu testen, da meist ein klar definierter Sollzustand fehlt. Accessibility hat das Potenzial, genau diese Sollzustände zu liefern.
Die Softwarequalitätsnorm ISO/IEC 25019:2023 hat nicht nur der Bedienbarkeit eine gewichtigere Rolle verliehen, sondern auch die Interaktionsfähigkeit des Systems muss inklusiv, selbsterklärend und flexibel sein. Daraus ergibt sich die zentrale Frage, ob alle Nutzer*innen in der Lage sind, ihre Ziele zu erreichen. Alle – ungeachtet eventueller Beeinträchtigungen.
Barrierefreiheit ist kein Randthema
Wenn bestimmte Personen aufgrund von Barrieren nicht in der Lage sind, Kernprozesse abzuschließen, ist das Produkt fehlerhaft und diese Exklusion wird sanktioniert – nicht nur von Menschen mit Behinderungen.
Erst Anfang des Jahres hat AccessiWay eine Studie veröffentlicht, die 2025 in Auftrag gegeben wurde. 6599 Leute aus 5 europäischen Ländern wurden befragt – ohne Referenz auf mögliche Beeinträchtigungen wohlgemerkt. 68,4% gaben an, bereits mindestens einen digitalen Vorgang wegen unzureichender Barrierefreiheit abgebrochen zu haben. Außerdem zeigt diese Studie, dass jüngere Befragte Barrierefreiheitsmängel deutlich weniger verzeihen als ältere.
Die Autor*innen halten fest: „Digital Natives erwarten schnelle, intuitive Erlebnisse. Wenn eine Website das nicht bietet, bleiben diese Konsument*innen nicht lange“.
Umgekehrt zeigt uns der Curb-Cut-Effekt, wie Optimierungen für Menschen mit Behinderungen allen zugutekommen. Viele Technologien, die für uns heute alltäglich sind, wurden als Assistive Technologien entwickelt, wie z.B. SMS, Hörbücher, Touchscreens und Sprachassistenten.
Die Messlatte
Die EU-Richtlinie 2019/882, besser bekannt unter der Bezeichnung European Accessibility Act (EAA), verpflichtet nicht nur zur Barrierefreiheit, sie liefert auch einen Messlattenkatalog für einschlägige Mindestanforderungen – EN 301 549.
Für die Webentwicklung beispielsweise wird dezidiert auf die Web Content Accessibility Guidelines, kurz WCAG, verwiesen. Mit der Version 2.2 wurde dieser Anforderungskatalog explizit mit den Forderungen des EAA erweitert. Damit haben wir ein Werkzeug zur Verfügung, um konkret messbar die Bedienbarkeit in jeder Phase der Entwicklung konsequent umzusetzen und zu testen.
Webentwicklung als Beispiel
In der modernen Webentwicklung haben JavaScript (JS)-Frameworks eine besondere Hürde eingebaut, derer wir uns gewahr sein müssen: Der Browser generiert aus dem DOM einen sogenannten Accessibility Tree, den die Schnittstelle zu Assistiven Technologien verwendet. Da die DOM-Struktur aus HTML generiert wird, und JS, wie auch CSS, erst danach in die Struktur gehängt wird, ist JS-Code nicht von Assistiven Technologien erfassbar.
Durch den Webstandard ARIA (Accessible Rich Internet Applications) können wir JS direkt in die Accessibility-API mappen. Dieser Weg ist aber aufwändiger und fehleranfälliger, als einfach semantische HTML-Elemente zu verwenden. Zum Beispiel beinhaltet ein HTML <button> Element bereits die Eigenschaften „Label“, „Tabindex“, usw. und ein onclick Event in HTML umfasst Maus, Tastatur und Touchscreen.
Ein JS onclick Event hingegen bezieht sich ausschließlich auf die linke Maustaste. Alles Weitere muss mit ARIA manuell dazu programmiert werden, und da die Frameworks semantisches HTML lange Zeit nicht unterstützt haben, konnten Entwickler*innen gar nicht anders, als eine Webseitenstruktur aus semantisch leeren <div> und <span> Elementen zu konstruieren, was wiederum Fokus-, Zustandskontrolle und Event Handling erschwert. Das ist nicht nur für Screenreader und andere Assistive Technologien ein Problem, sondern auch für Suchmaschinen und Übersetzungsprogramme unbrauchbar.
Die WCAG beschreiben vier Prinzipien: Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit. Ohne eine funktionierende grundlegende Struktur ist eine Webseite weder bedienbar noch robust.
Auch Design kann mehr, als nur auf Farbkontrast zu achten. Sind Widgets logisch gruppiert und beschriftet, sind sie auch bei starkem Zoom noch sinnvoll dargestellt und verständlich. Damit gibt es auch weniger Bedenken bei unterschiedlichen Bildschirmgrößen.
Usability durch Accessibility testen
Viele vermeintlich diffuse Fragen werden durch WCAG-Akzeptanzkriterien greifbar:
- Ist das Design intuitiv verständlich und in sich konsistent?
- Sind Formulare semantisch gruppiert, mit Labels versehen, nicht nur „placeholder“ und robust gegen Eingabefehler?
- Sind Pflichtfelder und restriktive Eingaben, wie ein Datum, ausreichend ausgewiesen?
- Ist Navigation mit der Tastatur möglich?
- Ist der Fokus da, wo er logisch hingehört?
- Wie sieht es beim Login aus? Sind Authentifizierungsmöglichkeiten redundant genug?
- Reicht die Zeit bis zum Timeout, oder kann man bei Bedarf verlängern? Ist der Prompt dazu im Fokus?
- Sind Bestätigungen kommuniziert durch brauchbare dynamische Statusmeldungen und nicht nur auf die Oberfläche geschrieben?
Für uns Tester*innen heißt das, bereits in der Planung kritische Flows zu definieren und eine ‚Assistive Technology‘-Matrix festzulegen. Diese Flowtests werden durchgeführt mit Screenreadern, Sprachsteuerung und exzessivem Zooming, auch für mobile Endgeräte. Ebenfalls manuell wird die UI auf Keyboardnavigation, Fokus-Reihenfolge und semantisch saubere Formularfelder getestet.
Wir können hier nicht alles automatisieren, aber es ist durchaus möglich, durch geeignete Tools in der Pipeline die HTML-Struktur als technische Basis auf Markup, Semantik, Labels und Landmarks zu prüfen. Linter, AXE oder WAVE finden dabei immerhin bis zu etwa 60% der gravierendsten Missstände.
Abschließend lässt sich einmal mehr betonen, dass es um mehr geht, als nur die gesetzlichen Vorschriften zu erfüllen. Barrierefreiheit konsequent mitzudenken verbessert die technische Substanz der Produkte allgemein. Das wiederum wirkt sich positiv auf andere Qualitätskriterien wie Leistungseffizienz, Kompatibilität, Zuverlässigkeit, Flexibilität und Wartbarkeit aus.
Quellen
- Digitale Barrieren: Studie zeigt hohe Abbruchraten bei Nutzern | Itwelt
- Directive – 2019/882 – EN – EUR-Lex
- EN 301549:2021. Accessibility requirements for ICT products and services – AccessibleEU
- Web Content Accessibility Guidelines (WCAG) 2.2
Zur Autorin
Maga. Tina Hildenbrandt ist studierte Linguistin und Test Engineer bei ATOS. Barrierefreiheit ist nicht nur ihr Herzensthema, sie gilt auch als Expertin für Accessibility in der Webentwicklung.