Neue Automatisierte Accessibility-Tests umsetzen: Technische Bauanleitung für zwei Prüfmodule

Im vorherigen Beitrag „Automatisierte Accessibility-Tests weiterdenken: Was sich schon im Design prüfen lässt“ haben wir Auswahl, Funktionsweise und Evaluation von neuen Accessibility Kriterien zum Testen in Design Tools beschrieben. Diese Bauanleitung übersetzt den Ansatz in zwei Plugin-Module, die Sie in ihre bestehenden Systeme integrieren können: Die Beschriftungsprüfung arbeitet überwiegend regelbasiert, die Sprachprüfung lokal oder optional KI-gestützt. Beide erzeugen Prüfhinweise; die abschließende Bewertung übernimmt ein Mensch im Nutzungskontext.

Technische Voraussetzungen und Eingabedaten
Die Verfahren nutzen die Prototypstruktur statt eines Screenshots. Für einen Frame sollte Ihr bestehendes Plugin folgende Daten auslesen:

Durchsuchen Sie nur sichtbare Knoten in der aktuellen Auswahl. Nutzen Sie möglichst Komponenten-Metadaten des Designsystems. Ebenennamen sind ein sprach- und projektspezifischer Rückfall und sollten konfigurierbar sein.

Prüfmodul 1: Abweichende Sprachen und Sprachfragmente finden

Ziel

Das Modul unterstützt WCAG 3.1.1 und 3.1.2. Es schätzt die Hauptsprache und zeigt wahrscheinliche Abweichungen bis hin zu einzelnen Passagen. Eigennamen, Fachbegriffe, Produktnamen und eingebürgerte Fremdwörter sind dabei nicht automatisch kennzeichnungspflichtige Sprachwechsel.

Implementierungsschritte

1. Texte sammeln. Lesen Sie jeden sichtbaren, nicht leeren Textknoten rekursiv aus. Behalten Sie die Node-ID für die spätere Markierung im Design.
2. Jeden Text klassifizieren. Ermitteln Sie pro Text die wahrscheinlichste Sprache und eine Konfidenz zwischen 0 und 1. Sehr kurze Texte wie „OK“, „Pro“ oder „Gift“ sind notorisch mehrdeutig; behandeln Sie sie als unsicher statt als eindeutigen Fehler.
3. Hauptsprache vorschlagen. Aggregieren Sie die Ergebnisse. Gewichten Sie längere, aussagekräftige Texte stärker als einzelne Wörter und schlagen Sie die Sprache mit dem höchsten Gesamtscore vor.
4. Korrektur zulassen. Die Hauptsprache muss überschreibbar sein, etwa bei mehrsprachigen Oberflächen oder einer verzerrenden Navigation.
5. Abweichungen markieren. Zeigen Sie Texte, deren Konfidenz für die gewählte Hauptsprache unter der eingestellten Schwelle liegt. Formulieren Sie das Ergebnis als Prüfhinweis, nicht als bestätigten Fehler.
6. Fragmente separat prüfen. Bei längeren Texten kann ein Modell abweichende Passagen mit Sprachcode und Konfidenz zurückgeben. Markieren Sie nur Fragmente oberhalb einer dokumentierten Schwelle.
7. Ergebnisse prüfbar machen. Zeigen Sie Text, erkannte Sprache, Konfidenz und Elementvorschau. Ein Klick sollte zum Originalknoten springen.

Architekturentscheidung

Bei externen Diensten müssen Datenfluss und Datenschutz geklärt sein. Begrenzen Sie parallele Anfragen, cachen Sie Ergebnisse, bieten Sie einen lokalen Rückfallmodus an und validieren Sie Antworten strikt.

Menschlicher Prüfpunkt

Die Designenden stellen sich dann Fragen wie: Ist dies tatsächlich eine andere natürliche Sprache oder ein Name, Fachbegriff beziehungsweise gebräuchliches Fremdwort? Soll die Passage in der Hauptsprache formuliert oder im späteren Code mit einer abweichenden Sprache ausgezeichnet werden? ODER Enthält der aktuelle Prototyp bereits echte Inhalte? Bei Platzhaltertext sollte die Prüfung vertagt und dokumentiert werden. Das Modul ist kein WCAG-Konformitätsnachweis: Erst die Umsetzung muss Sprache programmgesteuert bereitstellen, im Web beispielsweise über `lang`-Attribute.

Prüfmodul 2: Eingabefelder ohne plausible Beschriftung finden

Ziel

Das Modul unterstützt die frühe Prüfung von WCAG 3.3.2. Es sucht zu jedem Eingabeelement einen räumlich plausiblen Textkandidaten und legt fehlende oder mehrdeutige Treffer zur Prüfung vor. Der Abstand bleibt eine Heuristik: Ein naher Text kann ungeeignet, eine weiter entfernte gemeinsame Überschrift dagegen ausreichend sein.

Implementierungsschritte

1. Eingabeelemente erkennen. Identifizieren Sie Text- und Suchfelder, Auswahlelemente, Radio-Buttons und Checkboxen. Bevorzugen Sie Informationen des Designsystems und Ebenennamen nur als Rückfall.
2. Begrenzungsrahmen bestimmen. Speichern Sie für jedes Feld und jeden Text die absolute X-/Y-Position sowie Breite und Höhe.
3. Suchzonen bilden. Erweitern Sie den Begrenzungsrahmen um die erlaubten Abstände. Alle vier Richtungen sollten einzeln aktivierbar sein.
4. Kandidaten filtern. Ein Text ist beispielsweise ein Kandidat oberhalb des Feldes, wenn sein unterer Rand höchstens den erlaubten Abstand vom oberen Feldrand entfernt ist und er sich horizontal ausreichend mit dem Feld überlappt. Wenden Sie entsprechende Regeln auf die anderen Richtungen an.
5. Treffer priorisieren. Sortieren Sie mehrere Kandidaten nach Richtung, Abstand, Überlappung und inhaltlicher Plausibilität. Der nächste Text ist nicht immer das Label.
6. Unbeschriftete Felder melden. Zeigen Sie alle Felder ohne Kandidaten. Optional sollten auch mehrdeutige Fälle mit mehreren ähnlich plausiblen Kandidaten erscheinen.
7. Grenzfälle dokumentieren. Ermöglichen Sie „akzeptiert“, „bewusst anders gelöst“ und „muss geändert werden“. So werden bekannte Ausnahmen nicht bei jedem Durchlauf neu diskutiert.

Konfiguration der Abstandsheuristik

Nutzen Sie keinen vermeintlich universellen Pixelwert. Leiten Sie Standardabstände aus dem Designsystem ab und machen Sie sie pro Richtung anpassbar. Für robustere Treffer können zusätzlich derselbe Auto-Layout-Container, Ebenenreihenfolge und bekannte Label-Slots berücksichtigt werden. Eine sichtbare Suchzone erklärt, warum ein Element gefunden oder übersehen wurde.

Menschlicher Prüfpunkt

Für jeden Hinweis ist dann zu klären: Beschreibt der Text eindeutig, welche Eingabe erwartet wird? Ist eine zusätzliche Anweisung nötig, etwa ein Datumsformat oder eine Passwortregel? Bleibt die Beschriftung sichtbar, wenn das Feld ausgefüllt ist? Ein Placeholder allein ist häufig keine robuste Lösung. ODER Ist die sichtbare Beschriftung in der späteren Umsetzung auch programmatisch mit dem Feld verbunden? Der letzte Punkt ist entscheidend. WCAG 3.3.2 verlangt verständliche Beschriftungen oder Anweisungen. Die programmatische Beziehung zwischen Label und Eingabefeld wird zusätzlich durch andere Kriterien berührt, insbesondere WCAG 1.3.1. Ein Prototyping-Plugin kann die Umsetzung vorbereiten und annotieren, aber nicht garantieren.

Gemeinsames Ergebnis- und Statusmodell

Beide Module können dasselbe Ergebnisobjekt nutzen: Element-ID, Prüfregel, Status, Evidenz und nächster Schritt. Unterscheiden Sie Hinweise, bestätigte Probleme, verworfene Treffer und dokumentierte Ausnahmen. Zeigen Sie statt eines pauschalen Accessibility-Scores lieber Prüfumfang, Schwelle und menschliche Entscheidung und integrieren Sie dafür die entsprechenden User Interfaces in Ihre Bestandssoftware.

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.