Seite 2: Inhalte müssen für alle wahrnehmbar sein

Automatisierte Tools erkennen häufig nur, ob Inhalte vorhanden sind – nicht aber, ob sie für alle Nutzergruppen wirklich wahrnehmbar und hilfreich sind.

Ein klassischer Fall betrifft Bilder: Ein Beispiel, das in nahezu jedem Artikel zur Automatisierungslücke genannt wird, ist der Umgang mit Alternativtexten. Tools können erkennen, ob ein alt-Attribut vorhanden ist, aber sie können nicht beurteilen, ob der darin enthaltene Text inhaltlich sinnvoll ist. Ein Bild wie <img src="diagramm.png" alt="Bild" /> würde von allen gängigen Scannern als korrekt eingestuft, obwohl der Alternativtext keinerlei Information über das Diagramm vermittelt. Ein Screenreader-Benutzer erfährt damit nicht mehr als „Bild“, was aus fachlicher Perspektive wertlos ist. Genauso wenig hilfreich sind Alternativtexte wie „Exportiert aus Figma“ oder „Screenshot vom Handy. KI-generierte Inhalte können falsch sein“. Damit wird das WCAG-Erfolgskriterium 1.1.1 Nicht-Text-Inhalt formal erfüllt, inhaltlich aber weit verfehlt. Ein weiteres Problem besteht bei der Bewertung, ob ein Bild, das ohne Textalternative über background-image: url('images/background.png') eingefügt oder mit einem leeren alt-Attribut versehen wurde, tatsächlich rein dekorativ ist. Bei Grafiken, die Texte enthalten, besteht dieses Problem ebenfalls. Denn laut WCAG-Erfolgskriterium 1.4.5 Bilder eines Textes dürfen Texte im Bildformat nur dann verwendet werden, wenn eine bestimmte Darstellung essenziell ist. Doch was ist schon „essenziell“ für ein automatisiertes Tool?

Ein weiteres Beispiel betrifft Multimediainhalte: Bei Video- oder Audiodateien kann ein automatischer Test feststellen, dass eine Untertitelspur existiert, etwa durch <track kind="captions">. Aber er kann nicht prüfen, ob die Untertitel vollständig, synchron oder korrekt sind, ob visuelle Informationen korrekt wiedergegeben werden, oder ob Soundeffekte, Nebengeräusche oder wichtige visuelle Hinweise mitgeteilt werden. Das betrifft WCAG-Erfolgskriterien wie 1.2.2 Untertitel (aufgezeichnet), 1.2.3 Audiodeskription oder Medienalternative (aufgezeichnet), 1.2.4 Untertitel (Live) und 1.2.5 Audiodeskription (aufgezeichnet).

Semantisch nutzlos sind auch unpassende Werte für das autocomplete-Attribut, wie im folgenden Codeschnipsel:

<label for="customer">Customer name:<label/><input type="text"
id="customer" name="customer" autocomplete="street-address" />

Automatisierte Tools können problemlos feststellen, ob ein solches Attribut vorhanden ist. Sie können jedoch nicht bewerten, ob der gewählte Wert zum Eingabetyp passt und ob es sich bei der Eingabe um die Informationen über den Benutzer handelt, was die Bewertung von WCAG 1.3.5 Bestimmung des Eingabezwecks einschränkt.

Nutzlos können die Elemente auch dann sein, wenn sie zwar im DOM vorhanden sind, aber man mit ihnen nicht interagieren kann. Das kann passieren, wenn bei Buttons zum Stoppen und Abspielen der Inhalte in einem Mediaplayer die nötigen Event Listener fehlen oder ein <div>-Button nur auf click-Events reagiert und somit nicht per Tastatur bedienbar ist. Das stellt einen Verstoß gegen WCAG 1.4.2 Audio-Steuerelement dar.

Die Einschätzung der Funktionalität einer Seite ist nicht trivial. Wie können automatisierte Tools nämlich sicherstellen, dass die vollständige Funktionalität der Webseite erhalten bleibt, wenn User

• die Ausrichtung des Gerätes ändern (WCAG 1.3.4 Bildschirmausrichtung),
• den Text vergrößern (WCAG 1.4.4 Textgröße ändern) oder
• einen kleineren Viewport nutzen (WCAG 1.4.10 Umfluss (Reflow))?

Darüber hinaus entsteht die Bedeutung der Inhalte nicht nur durch den Text selbst, sondern auch durch ihre visuelle Anordnung und Struktur. Automatisierte Tools können diese semantische Ebene nicht zuverlässig rekonstruieren. Ein typisches Beispiel ist die Gruppierung von Eingabefeldern – etwa für Liefer- und Rechnungsadresse. Ob einzelne Felder logisch zusammengehören, lässt sich für Menschen anhand der visuellen Gestaltung sofort erkennen, während Tools lediglich die technische Struktur auslesen und keine semantischen Beziehungen erfassen können. Ähnliche Probleme entstehen, wenn optisch hervorgehobene Elemente falsch oder gar nicht ausgezeichnet werden: Etwa wenn eine Aufzählung visuell mit Strichen gestaltet ist, aber nicht als Liste (<li>) markiert wurde. Oder wenn das <q>-Element zweckentfremdet wurde, um Einrückungen zu erzeugen, obwohl es sich gar nicht um ein Zitat handelt.

Auch Überschriften sind ein häufiges Problemfeld. Nur weil ein Text groß und fettgedruckt erscheint, muss er nicht auch als Überschrift in HTML ausgezeichnet sein. Genauso wenig zuverlässig erkennen Tools, ob die vorhandene Überschriftenhierarchie inhaltlich stimmt. Eine h2-Überschrift mit dem Titel „Wellensittich“ wirkt technisch korrekt. Wenn er aber unter einer h2-Überschrift namens „Vögel“ steht, müsste er mit h3 ausgezeichnet sein. Automatisierte Tests können solche semantischen Fehleinordnungen nicht erkennen, weil ihnen das notwendige Kontextverständnis fehlt. Somit können sie das WCAG-Erfolgskriterium 1.3.1 Info und Beziehungen nicht zuverlässig prüfen.

Die Liste ließe sich noch um viele weitere Beispiele ergänzen. Aber insbesondere beim letzten gibt es Fortschritt. Zwar werden potenzielle Überschriften nicht automatisch erkannt, aber zumindest werden sie mittlerweile im Bereich „assisted testing“ der Browsererweiterung Silktide (und in manchen anderen ebenfalls) ausgewiesen. So besteht zumindest die Chance, das Problem mit menschlicher Hilfe zu identifizieren.

Alle User müssen mit den Inhalten interagieren können

Barrierefreie Inhalte – insbesondere interaktive – müssen nicht nur von allen wahrgenommen, sondern auch von allen bedient werden können. Nicht alle Nutzerinnen und Nutzer können eine Oberfläche mit der Maus steuern, doch moderne Technologien ermöglichen vielfältige Bedienformen: per Tastatur, per Schalter („Switch Control“), per Sprachsteuerung, per Augensteuerung oder mit weiteren assistiven Technologien.

Ein semantisches Element, zum Beispiel ein Button oder ein Link, das mit tabindex="-1" versehen wird, kann per Tastatur nicht mehr bedient werden: <button tabindex="-1">Konto löschen</button>. Das können automatisierte Tools erkennen und melden. Jedoch fehlt die automatisierte Überprüfung, ob das Element wegen pointer-events: none per Maus nicht mehr klickbar ist. Auch lässt sich nicht automatisiert erfassen, ob die dahinterliegende Funktionalität überhaupt implementiert ist – ein Button, der im HTML korrekt erscheint, aber keinen Event Listener enthält, ist für alle unbedienbar. Solche Fälle lassen sich gezielt (sprich: bei bewusster Berücksichtigung im Code) über End-to-End-Tests abfangen, nicht jedoch über Linter oder Browsererweiterungen.

Auch die sogenannte Tastaturfalle (WCAG 2.1.2 Keine Tastaturfalle) lässt sich nicht zuverlässig automatisiert erkennen. Dabei erreicht man zwar einen bestimmten Bereich der Seite per Tabulator, kann ihn aber nicht mehr per Tastatur verlassen. Auch hier sind die automatisierten Tools dadurch eingeschränkt, dass sie einzelne Zustände und keine Übergänge testen. Mit End-to-End-Testframeworks wie Playwright kann man mögliche Tab-Reihenfolgen (zum Beispiel gängige Interaktionsabfolgen) im Code simulieren und solche Probleme gezielt prüfen. Da sich Entwicklerinnen und Entwickler selbst um die Implementierung dieser Tests kümmern müssten, wäre das jedoch keine automatisierte Prüfung.

Die Sinnhaftigkeit der Fokusreihenfolge (WCAG 2.4.3 Fokus-Reihenfolge) lässt sich ebenfalls nicht automatisch feststellen. Moderne Layouttechniken wie CSS Flexbox mit der reverse-Option sorgen dafür, dass die visuelle Reihenfolge nicht der DOM-Reihenfolge entspricht. Automatisierte Tests melden in solchen Fällen oft keine Probleme, obwohl der tatsächliche Tab-Fokus völlig unlogisch verläuft:

<div style="display: flex; flex-direction: row-reverse;">
  <p>Eins</p>
  <p>Zwei</p>
  <p>Drei</p>
</div>

Visuell erscheint die Reihenfolge „drei, zwei, eins“. Im DOM lautet sie jedoch „eins, zwei, drei“. Und genau so, wie sie im DOM stehen, werden die Elemente per Tastatur fokussiert – also nicht so, wie sehende Nutzerinnen und Nutzer es erwarten würden. Das ist übrigens auch der Grund, weshalb man Reihen in einer Tabelle nie mit flex-direction: column-reverse sortieren, sondern mit JavaScript die tatsächliche Anordnung der DOM-Knoten anpassen sollte.

Bei der Interaktion mit den Seiteninhalten spielt die Zeit eine Rolle. Automatisierte Prüfungen laufen fast immer nur wenige Sekunden. Dadurch ist es sehr unwahrscheinlich, dass die Tools zuverlässig erkennen, ob Zeiteinschränkungen anpassbar sind – etwa ob man eine Login-Session rechtzeitig und einfach verlängern kann oder ob die Sitzung über 20 Stunden dauert und nicht verlängert werden soll (WCAG 2.2.1 Zeiteinteilung anpassbar). Solche Checks lassen sich nur mit gezielten manuellen oder speziell für diese Anforderung geschriebenen End-to-End-Tests abbilden.