Automatisierte Accessibility-Prüfung im Web: Möglichkeiten und Grenzen

Seite 3: Inhalte müssen verständlich sein

Um die Webseite bedienen zu können, müssen die Benutzerinnen und Benutzer deren Inhalte verstehen können. Dafür ist es notwendig, die Sprache der Webseite richtig anzugeben. Die automatisierten Checks können inzwischen auf das lang-Attribut im <html>-Tag prüfen: <html lang="de">. Ob die tatsächliche Sprache der angegebenen entspricht und ob es Abschnitte in einer abweichenden Sprache gibt, bleibt nach dieser Prüfung offen. Technisch sollte es aber möglich sein – Browser bieten mittlerweile Translator and Language Detector APIs, die die fehlenden Informationen liefern. Diese KI-basierten Werkzeuge sind zwar noch experimentell, könnten aber perspektivisch eine präzisere automatisierte Bewertung der WCAG-Erfolgskriterien 3.1.1 Sprache der Seite und 3.1.2 Sprache von Teilen ermöglichen.

Verständlichkeit betrifft jedoch weit mehr als nur Sprache. Ein zentraler Bereich ist die Kommunikation der Fehler bei Formulareingaben (WCAG 3.3.1 Fehlererkennung). Automatisierte Tools können leider nicht prüfen, ob alle relevanten Fehlermeldungen vorhanden sind und korrekt mit den zugehörigen Eingabefeldern verknüpft wurden. Eng damit verbunden ist das WCAG-Erfolgskriterium 3.3.3 Fehlerempfehlung. Automatisierte Tests bewerten aktuell nicht, ob Vorschläge zur Fehlerkorrektur nachvollziehbar, relevant oder hilfreich sind. Das können aktuell nur Nutzerinnen und Nutzer feststellen. Dabei ist es entscheidend, dass sie wissen, was falsch ist und wie sie den Fehler beheben können.

Folgendes Codebeispiel ist syntaktisch korrekt und sorgt dafür, dass die Fehlermeldung auch von assistiven Technologien angekündigt wird. Jedoch ist der Text selbst nicht hilfreich.

<label for="email">Email:</label>
<input id="email" type="email" aria-describedby="email-error">
<p id="email-error" class="error">
  Die Eingabe ist ungültig.
</p>

Ein weiterer Bereich betrifft WCAG 3.3.4 Fehlervermeidung (rechtliche, finanzielle, Daten). Bei Prozessen mit rechtlichen oder finanziellen Folgen bzw. Datenänderungen muss es möglich sein, Eingaben rückgängig zu machen, vor dem Absenden zu prüfen oder nochmals zu bestätigen und zu korrigieren. Automatisierte Tools können aktuell die Bedeutung und Konsequenzen eines Prozesses nicht abschätzen. Folglich wissen sie nicht, ob dieses WCAG-Kriterium Anwendung findet. Selbst wenn sie es könnten, wären sie nicht in der Lage, zu bewerten, ob eine der erwähnten Sicherheitsmaßnahmen vorhanden ist.

Auch redundante Eingaben (WCAG 3.3.7 Redundanter Eintrag) können automatisierte Prüfungen nicht zuverlässig erkennen. Ein Formular könnte die Adresse der Nutzerinnen und Nutzer mehrfach abfragen – als Liefer- und Rechnungsadresse. Das lässt sich einfach vermeiden, indem man ihnen anbietet, die Daten per Häkchensetzen zu übernehmen. Eine Vorbelegung der Daten, die nach dem Login ohnehin vorliegen, ist auch sinnvoll. Automatisiert lässt es sich jedoch schwer überprüfen, ob solche Mechanismen zur Vermeidung der erneuten Eingabe angeboten werden und ob die Vorbelegung sinnvoll ist, etwa aus Sicherheits- oder Geschäftsprozessgründen.

Apropos Sicherheit: Moderne Sicherheitsmechanismen können für viele Nutzergruppen erhebliche Barrieren beim Login darstellen. Die Anforderungen dafür sind im WCAG-Erfolgskriterium 3.3.8 Zugängliche Authentifizierung (Minimum) zusammengefasst. Ob ein Login-Prozess Menschen mit kognitiven Einschränkungen ausschließt, kann aktuell keine automatisierte Prüfung zuverlässig feststellen. Das liegt daran, dass die Tools nicht prüfen können, ob zum Beispiel Copy & Paste erlaubt ist, Passwortmanager verwendet werden können, biometrische Logins unterstützt werden oder der Prozess unzulässige kognitive Funktionstests verlangt (etwa das Lösen mathematischer Rätsel).

Inhalte und Markup müssen zuverlässig interpretiert werden können

Damit Inhalte langfristig barrierefrei bleiben, müssen sie von Browsern und assistiven Technologien zuverlässig interpretiert werden können. Dieses Prinzip wird in den WCAG unter anderem durch das Erfolgskriterium 4.1.2 Name, Rolle, Wert abgedeckt. Ziel ist es, sicherzustellen, dass interaktive Elemente ihren Zweck eindeutig vermitteln und sich ihr Zustand korrekt an assistive Technologien überträgt.

Automatisierte Tests können in diesem Bereich teilweise unterstützen. Sie sind in der Lage zu prüfen, ob interaktive Elemente über die Accessibility-APIs überhaupt einen Namen, eine Rolle und – sofern relevant – einen Wert bereitstellen. Ebenso können sie erkennen, ob ein benutzerdefiniertes Steuerelement keine oder unpassende semantische Information preisgibt, etwa in diesem Beispiel:

<button role="table">Absenden</button>

Hier würde ein automatisiertes Tool zu Recht melden, dass die Rolle "table" nicht zu der impliziten "button"-Rolle passt. Solche formalen Auffälligkeiten lassen sich zuverlässig automatisiert erfassen.

Die Grenzen der Automatisierung zeigen sich jedoch dort, wo semantische Angemessenheit gefragt ist. Tools können nicht beurteilen, ob eine verwendete Rolle inhaltlich korrekt oder sinnvoll ist. Formal ist das Markup des nächsten Beispiels valide und wird von automatisierten Tests nicht beanstandet.

<nav role="menu">
  <a role="menuitem" href="/start">Start</a>
  <a role="menuitem" href="/kontakt">Kontakt</a>
</nav>

Semantisch ist es jedoch problematisch: Eine Hauptnavigation ist kein Menü im Sinne der ARIA-Spezifikation. Dieses Muster ist für die Desktopinteraktion vorgesehen und fordert entsprechende Tastaturfunktionalität, unter anderem die Navigationsmöglichkeit zwischen den Optionen per Pfeiltasten. Für eine typische Website wäre eine einfache Struktur aus <nav> und einer ungeordneten Liste deutlich einfacher und geeigneter:

<nav>
  <ul>
    <li><a href="/start">Start</a></li>
    <li><a href="/kontakt">Kontakt</a></li>
  </ul>
</nav>

Ob die Werte im Rahmen der Interaktion richtig gesetzt werden, lässt sich ebenfalls nicht vollständig automatisiert erfassen. Ein Beispiel dafür ist aria-expanded="true" bei einem Button, der ein Hamburger-Menü aus- und einklappt. Browsererweiterungen würden hier nicht erkennen, wenn der Wert nicht zum aktuellen Zustand des Menüs passt. Darauf können Entwicklerinnen und Entwickler jedoch gezielt in ihren Unit- oder End-to-End-Tests prüfen.

Selbst wenn alle Zustände und Rollen richtig gesetzt wurden, kann es sein, dass die gewünschten Informationen nicht richtig oder nicht vollständig angekündigt werden, da sie entweder vom Browser, von den Acessibility-APIs im Betriebssystem oder von dem jeweiligen Screenreader noch nicht unterstützt werden. Ein Beispiel ist das Attribut aria-busy, das zeigt, ob ein Element gerade geändert wird, und assistiven Technologien signalisiert, dass die Aktualisierung noch nicht abgeschlossen ist. Man könnte sich diese Funktionalität als einen „Loading Spinner“ für Screenreader vorstellen. Leider können aktuell nicht alle Screenreader damit umgehen. Das wissen automatisierte Checker nicht und lassen die Implementierung ohne Beanstandungen durchgehen.

Ein weiteres typisches Problem im Kontext robuster und zuverlässig interpretierbarer Inhalte betrifft dynamisch nachgeladene Inhalte ohne geeignete Screenreader-Benachrichtigung. Fehlen explizite Statusmeldungen mithilfe von ARIA-Live-Regionen, erhalten die Nutzenden keine Rückmeldung darüber, dass sich der Inhalt der Seite geändert hat. Aktionen wie das Laden von Suchergebnissen, das Öffnen von Filtern oder das erfolgreiche Absenden eines Formulars bleiben damit unsichtbar. Aus Sicht automatisierter Tests bleibt die Struktur der Seite vor und nach der Änderung valide. Sie erkennen nämlich nicht, wenn eine zusätzliche Benachrichtigung für blinde Nutzerinnen und Nutzer notwendig und hilfreich ist. Somit müssen Developer die Erfüllung des WCAG-Erfolgskriteriums 4.1.3 Statusmeldungen selbst bewerten.