Automatisierte Accessibility-Tests weiterentwickeln: Was sich schon im Design prüfen lässt

Mehr automatisieren – mit klarer Rollenverteilung

In unserem Beitrag „Wo liegen auch in Zukunft die Grenzen automatisierter Accessibility-Tests?“ haben wir gezeigt: Regelbasierte Tests kontrollieren eindeutig messbare Eigenschaften; KI kann zusätzlich Zusammenhänge interpretieren und Hinweise priorisieren. Sobald Bedeutung, Interaktion und Nutzungskontext entscheiden, bleibt menschliche Bewertung unverzichtbar. KI verschiebt die Grenze des Automatisierbaren, ist aber kein Allheilmittel.

Die Konsequenz lautet dennoch nicht, weniger zu automatisieren. Automatisiert werden sollten Aufgaben mit belastbaren Eingabedaten; wo Kontextwissen nötig ist, übernimmt der Mensch. Dieser Shift-Left-Ansatz bringt Barrierefreiheit aus dem fertigen Code in den Gestaltungsprozess. Zum Beispiel enthalten Prototypen in Figma dafür mehr verwertbare Informationen als ein Screenshot. Texte, Komponenten, Ebenennamen, Positionen und Abstände liegen strukturiert vor. Deshalb haben wir untersucht, welche bislang übersehenen Accessibility-Kriterien sich mit diesen Informationen schon während des Prototypings sinnvoll prüfen lassen.

Von sechs häufigen Fehlern zu zwei geeigneten Prüffällen

Als Ausgangspunkt verwendeten wir den WebAIM Million Report 2025. Die sechs häufigsten automatisch erkennbaren Fehler machten zusammen 96 Prozent aller gefundenen Fehler aus. Wir glichen sie mit den Möglichkeiten bestehender Prototyping-Werkzeuge ab.

Die Auswahl fiel auf die Aspekte der Formularbeschriftungen und der Sprache. Beide Probleme sind praktisch relevant, werden von vorhandenen Designwerkzeugen aber nur unzureichend unterstützt. Gleichzeitig liefern Prototypen bereits Anhaltspunkte für eine Prüfung: die räumliche Beziehung zwischen Eingabefeldern und Texten sowie die tatsächlichen Textinhalte einer Oberfläche. Damit adressiert das Verfahren drei WCAG-Erfolgskriterien: 3.1.1 „Sprache der Seite“, 3.1.2 „Sprache von Teilen“ und 3.3.2 „Beschriftungen oder Anweisungen“.

Warum halbautomatisch statt vollautomatisch?

Eine automatische Prüfung ist besonders stark, wenn sie eindeutige Eigenschaften messen kann. Sie kann beispielsweise alle Texte eines ausgewählten Frames auslesen, Sprachen klassifizieren oder Abstände zwischen Elementen berechnen. Sie weiß jedoch nicht zuverlässig, ob ein nahegelegener Text das Feld inhaltlich verständlich beschreibt. Auch Eigennamen, Fachbegriffe oder eingebürgerte Fremdwörter sind nicht automatisch ein kennzeichnungspflichtiger Sprachwechsel. Deshalb trennt unser Ansatz zwei kollaborative Aufgaben:

1. Das System durchsucht den Prototyp, berechnet Wahrscheinlichkeiten und macht verdächtige Elemente sichtbar.
2. Der Mensch bewertet den Kontext und entscheidet, ob und wie der Entwurf angepasst oder für die Entwicklung annotiert werden soll.

Das Ergebnis ist kein automatischer WCAG-Nachweis, sondern eine fokussierte Entscheidungshilfe. Sie reduziert die Menge der Elemente, die Designende manuell betrachten müssen, ohne ihnen die fachliche Entscheidung abzunehmen.

So funktioniert der Prototyping-Assistent

Der Demonstrator wurde als Figma-Plugin umgesetzt. Der Ablauf besteht für beide Prüfungen aus vier Schritten:

1. Oberfläche auswählen: Ein Frame oder ein anderer Bereich des Prototyps wird markiert.
2. Prüfung wählen: Zur Auswahl stehen Sprachprüfung und Beschriftungsprüfung.
3. Prüfung konfigurieren: Für Sprache werden Erkennungsverfahren, Zielsprache und Konfidenzschwelle gewählt. Für Beschriftungen lassen sich zulässige Abstände oberhalb, rechts, unterhalb und links eines Eingabefeldes festlegen.
4. Treffer beurteilen: Auffällige Elemente werden einzeln mit Vorschau, Positionsdaten beziehungsweise Sprachwahrscheinlichkeit angezeigt.

Verstehen die Designenden das Verfahren und hilft es ihnen?

Für die Evaluation rekrutierten wir 18 Personen mit UX-Erfahrung über die Plattform Prolific. Sie beurteilten die Sprachprüfung anhand von vier mobilen GUI-Prototypen und die Beschriftungsprüfung anhand eines weiteren Prototyps.

Die Spracherkennung erwies sich dabei als zuverlässig: Fast alle Teilnehmenden sahen die Dokumentsprache als korrekt erkannt an, und eine deutliche Mehrheit fand keine übersehenen fremdsprachigen Fragmente. Auch die Beschriftungsprüfung wurde positiv beurteilt. Die Teilnehmenden verstanden das Vorgehen, hielten die Funktion für hilfreich zur Verbesserung der Barrierefreiheit und sahen Potenzial, entsprechende Warnungen in die eigene Gestaltung einfließen zu lassen.

Insgesamt bestätigen die Ergebnisse die grundsätzliche Machbarkeit des halbautomatisierten Ansatzes. Zugleich zeigte die Bewertung der Bedienoberfläche, dass Komplexität und Erläuterungen noch besser an unterschiedliche Vorkenntnisse angepasst werden sollten.

Das eigentliche Ergebnis ist kein weiteres Plugin

Accessibility-Werkzeuge sind bereits stark fragmentiert. Unser Ziel ist deshalb nicht, noch ein isoliertes Plugin dauerhaft zu etablieren. Die beiden Prüfverfahren sind als übertragbare Bausteine gedacht, die bestehende Accessibility-Plugins in Figma oder anderen Designwerkzeugen übernehmen können. Wie sich beide Module technisch umsetzen lassen, beschreibt der Folgebeitrag “Neue Automatisierte Accessibility-Tests umsetzen: Technische Bauanleitung für zwei Prüfmodule”.

Mit diesem Verfahren zeigen wir auch semantisch anspruchsvollere Kriterien lassen sich in der Designphase unterstützen, wenn Automatisierung und menschliches Urteil klar getrennt werden.

Diese Inhalte basieren auf der Forschung von Wegener, Kretzer, Nicolay, Maedche (2026) mit dem Titel „A Semi-Automated Prototyping Assistant for Accessibility: Addressing Missing Form Labels and Document Language in Early Design Stages“. Der wissenschaftliche Artikel dazu ist ein Open-Access-Dokument.