Warum Overlays fehlerhafte HTML-Semantik nicht zuverlässig reparieren können

Buttons müssen in HTML korrekt ausgezeichnet werden. Andernfalls können Screenreader und Tastaturnutzer nicht zuverlässig erkennen, um welche Art von Bedienelement es sich handelt und wie es bedient werden soll.

Ein visuell wie ein Button gestaltetes <div> ist technisch zunächst nur ein allgemeiner Container. Aus dem Quellcode geht nicht hervor, ob dieses Element eine Schaltfläche, eine Überschrift, ein Menüpunkt, ein aufklappbarer Bereich oder etwas völlig anderes sein soll.

Genau hier liegt eine grundlegende Grenze von Accessibility-Overlays.

Software kann die Bedeutung eines Elements nicht sicher erraten

Webseiten enthalten häufig Elemente, die visuell eine bestimmte Funktion vermitteln, semantisch aber falsch oder unvollständig umgesetzt sind. Typische Beispiele sind:

• ein <div>, das wie ein Button gestaltet wurde,
• ein anklickbares <span>,
• eine Überschrift, die nur durch Schriftgröße und Fettdruck hervorgehoben wird,
• ein eigenes Steuerelement ohne verständlichen Namen,
• ein Menü, dessen Einträge keine korrekten Rollen und Zustände besitzen.

Für Menschen, die die Seite sehen und mit der Maus bedienen, kann die beabsichtigte Funktion möglicherweise erkennbar sein. Für Browser und assistive Technologien ist diese Absicht jedoch nicht automatisch vorhanden.

Software kann zwar Muster untersuchen, etwa CSS-Klassen, Klick-Ereignisse, Position, Farbe oder Beschriftung. Daraus lässt sich aber nicht zuverlässig bestimmen, welche semantische Rolle der Entwickler tatsächlich beabsichtigt hat.

Ein anklickbares <div> könnte beispielsweise sein:

• ein Button,
• ein Link,
• ein Schalter,
• ein Register,
• ein Menüpunkt,
• ein aufklappbarer Bereich,
• ein Dialogauslöser,
• oder lediglich ein Container mit einem Klick-Ereignis.

Diese Varianten benötigen unterschiedliche Rollen, Tastaturbefehle, Zustände und Regeln für das Fokusmanagement.

Ein Button ist mehr als ein anklickbares Element

Ein korrektes HTML-Button-Element stellt bereits wichtige Eigenschaften bereit:

• Es kann mit der Tastatur fokussiert werden.
• Screenreader geben es als Button aus.
• Es lässt sich mit der Eingabetaste oder der Leertaste aktivieren.
• Es wird in der richtigen Rolle an die Accessibility API des Betriebssystems übermittelt.
• Browser und assistive Technologien können sein Verhalten weitgehend vorhersehbar verarbeiten.[1][2]

Wird stattdessen ein allgemeines Element verwendet, müssen diese Eigenschaften vollständig nachgebaut werden. Dazu gehören unter anderem:

• eine korrekte Rolle,
• ein verständlicher zugänglicher Name,
• die Aufnahme in die Fokusreihenfolge,
• die Aktivierung mit den vorgesehenen Tasten,
• ein sichtbarer Tastaturfokus,
• gegebenenfalls Zustände wie „gedrückt“, „ausgewählt“ oder „aufgeklappt“,
• sowie ein korrektes Fokusmanagement nach der Aktivierung.

Ein Overlay müsste deshalb nicht nur erkennen, dass ein Element anklickbar ist. Es müsste außerdem wissen, welche Funktion es erfüllt, welches Interaktionsmuster dazu gehört und was nach der Aktivierung geschehen soll.

Das lässt sich aus fehlerhaftem HTML nicht zuverlässig ableiten.

Die Bezeichnung „Tastaturbedienbarkeit“ ist kein Nachweis

Manche Overlays bieten Funktionen an, die mit Begriffen wie „Tastaturnavigation“ oder „Tastaturbedienbarkeit“ bezeichnet werden. Eine solche Bezeichnung belegt jedoch nicht, dass sämtliche Funktionen einer Webseite anschließend vollständig mit der Tastatur bedienbar sind.

In einem praktischen Test ließ sich zeigen, dass ein fehlerhaft ausgezeichnetes Bedienelement auch nach Aktivierung einer solchen Funktion nicht zuverlässig wie ein nativer Button verwendet werden konnte. Die zugrunde liegende semantische Barriere blieb bestehen.

Dieser Befund ist technisch nachvollziehbar: Die Software konnte nicht sicher erkennen, welche Rolle das Element haben sollte und welches vollständige Tastaturverhalten erforderlich war.

Das bedeutet nicht, dass jede Funktion eines Overlays immer wirkungslos ist. Es zeigt aber eine entscheidende Grenze:

Ein Overlay kann nicht zuverlässig garantieren, dass falsch oder nicht semantisch ausgezeichnete Bedienelemente nachträglich vollständig tastaturbedienbar und screenreaderkompatibel werden.

Tastaturbedienbarkeit ist mehr als Tabulatornavigation

Vollständige Tastaturbedienbarkeit bedeutet nicht nur, dass sich ein Element mit der Tabulatortaste erreichen lässt.

Zu einer funktionierenden Tastaturbedienung gehören unter anderem:

• alle Funktionen sind ohne Maus erreichbar,
• die Fokusreihenfolge ist nachvollziehbar,
• der aktuelle Fokus ist sichtbar,
• Elemente lassen sich mit den erwarteten Tasten bedienen,
• Fokuswechsel erfolgen sinnvoll,
• Tastaturfallen werden vermieden,
• und benutzerdefinierte Komponenten folgen etablierten Interaktionsmustern.[3][4]

Ein Overlay, das lediglich zusätzliche Tabulatorstopps erzeugt oder Klick-Ereignisse auf Tastatureingaben überträgt, stellt deshalb noch keine vollständige Tastaturbedienbarkeit her.

Automatische Reparaturen benötigen eindeutige Informationen

Automatische Werkzeuge können nur zuverlässig mit Informationen arbeiten, die im Quellcode vorhanden oder eindeutig ableitbar sind.

Fehlt die Semantik, fehlt der Software ein wesentlicher Teil der notwendigen Information. Sie müsste die Absicht des Entwicklers erraten.

Das betrifft nicht nur Buttons. Dasselbe Problem tritt bei vielen anderen Strukturen und Komponenten auf:

• Ist ein großer, fett gesetzter Text eine Überschrift?
• Falls ja: Ist er eine Überschrift erster, zweiter oder dritter Ebene?
• Ist ein anklickbarer Text ein Link oder ein Button?
• Ist ein Symbol dekorativ oder inhaltlich relevant?
• Öffnet ein Element einen Dialog oder klappt es nur einen Bereich auf?
• Ist eine Gruppe von Elementen eine Liste, eine Navigation oder eine Registerkarten-Komponente?
• Welche Fehlermeldung gehört zu welchem Eingabefeld?
• Wohin muss der Fokus nach dem Öffnen oder Schließen eines Dialogs gesetzt werden?

Ohne verlässliche Informationen im HTML kann Software diese Fragen nicht mit ausreichender Sicherheit beantworten.

KI löst das Grundproblem ebenfalls nicht automatisch

Auch KI-gestützte Verfahren können Muster besser erkennen und Wahrscheinlichkeiten berechnen. Sie können beispielsweise vermuten, dass ein bestimmtes Element wahrscheinlich eine Schaltfläche oder eine Überschrift ist.

Eine Vermutung ist jedoch keine sichere technische Grundlage.

Für eine barrierefreie Benutzerschnittstelle müssen Rollen, Namen, Zustände und Interaktionen korrekt sein. Eine falsche automatische Zuordnung kann neue Barrieren erzeugen oder bestehende Probleme verschärfen.

KI kann Entwickler möglicherweise bei der Analyse und Fehlerbehebung unterstützen. Sie ersetzt aber nicht die fachliche Entscheidung darüber, welche Bedeutung und welches Verhalten ein Element tatsächlich haben soll.

Overlays ändern nicht die Verantwortung für den Quellcode

Fachorganisationen weisen seit Jahren darauf hin, dass Overlays keine zuverlässige Alternative zu barrierefreier Entwicklung sind.[5][6]

Die nachhaltige Lösung besteht darin, Barrieren dort zu beheben, wo sie entstehen:

• im HTML,
• in den verwendeten Komponenten,
• im Designsystem,
• in den JavaScript-Interaktionen,
• im Content-Management-System,
• und in den Entwicklungs- und Testprozessen.

Für eine Schaltfläche bedeutet das in der Regel: ein natives <button>-Element verwenden.

Nur wenn ein natives HTML-Element technisch nicht geeignet ist, müssen Rolle, Tastaturverhalten, Zustände und Fokusmanagement vollständig selbst implementiert und anschließend manuell getestet werden.

Fazit

Overlays können die Bedeutung fehlerhaft umgesetzter HTML-Elemente nicht zuverlässig rekonstruieren.

Ein <div> enthält keine Information darüber, ob es eigentlich ein Button, eine Überschrift, ein Link oder ein anderes Steuerelement sein soll. Ohne diese Information kann Software die erforderliche Semantik und das passende Bedienverhalten nur vermuten.

Deshalb gilt:

Barrierefreiheit entsteht nicht durch das nachträgliche Erraten fehlender Semantik, sondern durch korrekte HTML-Strukturen, zugängliche Komponenten und manuelle Tests.

Eine Funktion mit der Bezeichnung „Tastaturbedienbarkeit“ ist kein Beleg dafür, dass eine Webseite tatsächlich vollständig mit der Tastatur bedienbar ist. Entscheidend ist nicht der Name einer Funktion, sondern das überprüfbare Verhalten der Webseite.

Fußnoten

1. WHATWG: The button element. Der HTML-Standard definiert das native <button>-Element und sein Verhalten. https://html.spec.whatwg.org/multipage/form-elements.html#the-button-element
2. W3C Web Accessibility Initiative: H91: Using HTML form controls and links. Die Technik empfiehlt native HTML-Elemente, um Tastaturbedienbarkeit und Interoperabilität mit assistiven Technologien bereitzustellen. https://www.w3.org/WAI/WCAG22/Techniques/html/H91
3. W3C Web Accessibility Initiative: Understanding Success Criterion 2.1.1: Keyboard. Sämtliche Funktionen müssen über eine Tastaturschnittstelle bedienbar sein. https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html
4. W3C Web Accessibility Initiative: ARIA Authoring Practices Guide – Button Pattern. Der Leitfaden beschreibt das erwartete Tastaturverhalten von Buttons. https://www.w3.org/WAI/ARIA/apg/patterns/button/
5. European Disability Forum und International Association of Accessibility Professionals: Joint statement on accessibility overlays, 17. Mai 2023. Die Organisationen erklären, dass Overlays Barrierefreiheit und Rechtskonformität nicht garantieren. https://www.edf-feph.org/publications/joint-statement-on-accessibility-overlays/
6. Overlay Fact Sheet: Overlay Fact Sheet. Die Erklärung beschreibt die technischen Grenzen automatischer Overlay-Reparaturen und dokumentiert mögliche Interferenzen mit assistiven Technologien. https://overlayfactsheet.com/