zurück zum Artikel

Tools können dabei helfen, die Barrierefreiheit von Webanwendungen zu prüfen – doch an zahlreichen Stellen bleibt menschliches Verständnis gefragt.

Mit dem European Accessibility Act (EAA) und seiner nationalen Umsetzung durch das Barrierefreiheitsstärkungsgesetz (BFSG) gelten seit Juni 2025 in Deutschland verbindliche Anforderungen für zahlreiche digitale Produkte und Dienstleistungen. Parallel dazu wurden die organisatorischen Voraussetzungen geschaffen: Die zuständige Marktüberwachungsbehörde ist eingerichtet und nimmt schrittweise ihre Arbeit auf. Damit rückt Barrierefreiheit für viele Unternehmen erstmals in den konkreten Fokus von Compliance, Risikoabwägung und Produktverantwortung.

Maria Korneeva

Maria Korneeva ist Frontend Technology Lead und Google Developer Expert mit Fokus auf Angular und Barrierefreiheit. Sie arbeitet freiberuflich an Frontend-Anwendungen, leitet Workshops und teilt ihre Erfahrungen auf Konferenzen und Meetups sowie in ihrem Buch „Barrierefreie Webentwicklung: von den Grundlagen bis zur praktischen Umsetzung“.

Und es wächst der Wunsch nach effizienten, skalierbaren Lösungen. Viele Organisationen hoffen auf automatisierte Accessibility-Checks als schnellen und möglichst vollständigen Weg zur Konformität. Entsprechend populär sind Linter, Browser-Extensions, CI/CD-Integrationen und KI-gestützte Prüfwerkzeuge. Automatisierung ist dabei ein wichtiges und sinnvolles Werkzeug – doch sie hat klare technische Grenzen.

Denn zahlreiche Barrieren lassen sich nicht maschinell erkennen. Sie entstehen durch fehlenden Kontext, unklare Bedeutung, komplexe Interaktionen oder mangelnde Verständlichkeit – Aspekte, die menschliches Urteilsvermögen erfordern. Dieser Artikel zeigt, welche Arten von Accessibility-Tools es gibt, welche Aufgaben sie sinnvoll übernehmen können und warum ein erheblicher Teil der Barrieren auch mit modernster Automatisierung unsichtbar bleibt.

Testwerkzeuge und ihre Grenzen

Um die Möglichkeiten und Grenzen automatisierter Barrierefreiheitsprüfungen zu verstehen, lohnt sich zunächst ein Blick auf die unterschiedlichen Werkzeugtypen und darauf, welche Aspekte von Accessibility sie jeweils erfassen können.

Linter sind statische Analysetools für Quellcode. Sie erkennen syntaktische oder strukturelle Fehler, etwa ob ein alt-Attribut fehlt oder ein Button kein Label besitzt. Allerdings haben sie keine Kenntnis darüber, wie sich Seiten im Browser verhalten, wie Fokusabläufe funktionieren oder ob interaktive Komponenten korrekt reagieren. Statische Tools sehen nur Code – nicht Nutzung.

Browser-Extensions analysieren hingegen das Document Object Model (DOM) im gerenderten Zustand und können so mehr erkennen als statische Analyzer. Dennoch bleiben sie „Snapshot-Tools“: Sie bewerten einen Zustand, aber nicht die Interaktion über mehrere Schritte hinweg. Komplexe Fokusänderungen, Tastaturfallen oder dynamisch aktualisierte Inhalte bleiben typischerweise unsichtbar.

Unit-Test-Plug-ins sind nützlich, um bestimmte einzelne Komponenten auf Barrieren zu prüfen. Allerdings decken Unit-Tests die Funktionalität (zum Beispiel Tastaturbedienbarkeit) nur einer Komponente ab und bilden typischerweise keine vollständigen Nutzerflows ab.

End-to-End-Testtools bieten eine größere Abdeckung. Sie können komplexere Interaktionen simulieren, etwa die Fokussteuerung beim Öffnen und Schließen eines Modals, also eines Dialogs, der sich über die Inhalte der Seite legt und oft eine zusätzliche Aktion beinhaltet. An solche Testszenarien müssen Entwicklerinnen und Entwickler jedoch selbst denken. Werden Accessibility-Plug-ins integriert, lassen sich einige Aspekte automatisiert prüfen. Das umfangreichste Ergebnis erhält man, indem man Testfälle für wichtige Prozesse selbst schreibt und zusätzlich verschiedene Zustände seiner Website über automatisierte Plug-ins prüfen lässt. Doch auch dann bleibt ein grundsätzliches Problem: End-to-End-Tests wissen nicht, ob ein Bedienablauf „logisch“ oder „verständlich“ ist. Sie führen Befehle aus – aber sie „erleben“ die Nutzung nicht so, wie es ein Mensch tut.

CI/CD-Scanner automatisieren Prüfungen im Build- oder Deployment-Prozess. Sie eignen sich besonders gut dafür, typische fehlerhafte Muster frühzeitig aufzudecken und Regressionen zu vermeiden. Ihre Grenzen sind jedoch die gleichen wie die der zugrunde liegenden Tools. Ob man Linter, Browsererweiterungen, Unit-Tests oder End-to-End-Tests einbindet: Sie prüfen Code, Struktur und einfache Interaktionen – aber keine komplexen Navigationsabläufe oder inhaltlichen Bedeutungen.

Alle diese Werkzeuge leisten wertvolle Beiträge im Entwicklungsprozess. Doch wie viel Testaufwand lassen sie noch übrig?

Vorträge zu Accessibility: Heise-Konferenz enterJS 2026

Mehr über Accessibility im Web [1] erfährst du auf der enterJS 2026 [2] am 16. und 17. Juni in Mannheim. Die Konferenz dreht sich rund um die JavaScript/TypeScript-Entwicklung im Enterprise-Bereich. Vergünstigte Frühbuchertickets [3] sind im Online-Ticketshop erhältlich.

Wie viel Automatisierung wirklich leisten kann: Erkenntnisse aus Studien und Praxis

Mehrere Studien haben untersucht, wie hoch der Anteil der Barrieren ist, den automatisierte Tools tatsächlich erkennen können. Eine umfassende Analyse [4] des Accessibility-Software-Anbieters Deque Systems ergab 2024, dass dessen automatisierte Tests etwa 57 Prozent aller Accessibility-Probleme in realen Audits identifizieren konnten. Mit KI-Unterstützung will das Unternehmen sogar gut 80 Prozent erreicht haben [5].

Accessibility-Praktikerinnen und -Praktiker sehen die Wirksamkeit der automatisierten Tools deutlich eingeschränkter und schätzen, dass sich nur 20 bis 40 Prozent [6] der potenziellen Barrieren technisch erkennen lassen. Mehrere Expertinnen und Experten, darunter Adrian Roselli [7] und Steven Faulkner [8], berichten aus umfangreichen Feldtests, dass automatisierte Checks sogar nur 4 bis 10 Prozent der wirklichen Probleme erkennen.

Womit lässt sich diese Diskrepanz in den Schätzungen erklären? Natürlich unterscheiden sich die Zahlen der Marketing-Abteilung und der unabhängigen Accessibility-Beratung, weil sie damit unterschiedliche Ziele verfolgen. Auch die absichtlich eingefügten Bugs, die die Testseiten enthalten, unterscheiden sich, und somit auch die Testergebnisse. WCAG-Versionen (Web Content Accessibility Guidelines), genutzte Tools – all das sorgt für eine hohe Varianz in Schätzungen.

Trotz der Unterschiede zeigen diese Zahlen eindeutig, dass die existierenden Tools noch nicht hundertprozentig beurteilen können, ob eine Website barrierefrei ist. Selbst die formelle Prüfung der WCAG-Kriterien ist noch nicht zu 100 Prozent automatisiert möglich.

Typische Limitierungen und Fallbeispiele

Auch wenn Barrierefreiheit deutlich mehr als stupide Einhaltung der WCAG-Erfolgskriterien erfordert, stellen diese Richtlinien eine fundierte Checkliste zum Einstieg dar. Die darin enthaltenen Anforderungen betreffen sowohl die technische als auch die semantische Seite der Inhalte, das heißt, wie sie programmatisch zur Verfügung gestellt werden und wie verständlich sie formuliert sind.

Automatisierte Accessibility-Tools können in erster Linie Strukturen, Muster und technische Eigenschaften prüfen. Sie erkennen fehlende Attribute, inkorrekte Rollen oder syntaktische Fehler – aber sie verstehen nicht, was Inhalte bedeuten, wie Nutzerinnen und Nutzer mit einer Anwendung interagieren oder wie logisch ein Interface aufgebaut ist.

Deswegen lohnt sich der Blick auf die WCAG-Kriterien aus folgender Perspektive: Welche Anforderungen betreffen nicht nur Strukturen und formelles Vorhandensein von bestimmten Elementen, sondern auch Aspekte wie intuitive Nutzung, Interpretation, Kontext und Relevanz? Dabei stehen die Kriterien der Konformitätsstufen A und AA (siehe Infokasten) im Fokus, da sie von sämtlichen Barrierefreiheitsgesetzen als rechtliche Anforderung genannt werden. Die WCAG-Richtlinien basieren auf den Grundprinzipien der Barrierefreiheit für Webinhalte – Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit. Rund um diese Prinzipien sind auch die Beispiele in diesem Artikel gruppiert.

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.

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 [9], 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 [10]. 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 [11]. 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.

Automatisierung allein reicht nicht aus

Die genannten Beispiele machen deutlich: Automatisierte Tools sind ein wichtiger Bestandteil, um die Barrierefreiheit von Webseiten und Webanwendungen zu prüfen, aber allein reichen sie nicht aus. Browsererweiterungen, Linter und Unit-Tests prüfen jeweils nur Momentaufnahmen des Codes oder der Oberfläche. Deshalb können sie die Barrierefreiheit bestimmter Funktionen – etwa komplexer Interaktionen – nicht zuverlässig bewerten.

Diese Lücke lässt sich teilweise durch speziell entwickelte Testfälle in End-to-End-Tests schließen. Dennoch bleiben viele Barrieren bestehen, die nur mit menschlichem Verständnis erkannt werden können. Sie hängen eng mit Semantik, Sprache, Interaktion, Erwartungen und dem Nutzungskontext zusammen. Während Tools vor allem Muster erkennen, verstehen Menschen die Bedeutung dahinter.

Die Konsequenz ist klar: Wer barrierefreie Webangebote entwickeln möchte, muss verschiedene Ansätze kombinieren. Automatisierte Tests, manuelle Prüfungen und das Feedback echter Nutzerinnen und Nutzer ergänzen sich – erst ihr Zusammenspiel führt zu wirklich barrierefreien Lösungen.

(mai [12])

URL dieses Artikels:
https://www.heise.de/-11151635

Links in diesem Artikel:
[1] https://enterjs.de/veranstaltung-86382-0-zukunft-der-web-accessibility-neue-ansaetze-neue-tools-neue-chancen.html?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_enterJS.empfehlung-ho.link.link
[2] https://enterjs.de/?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_enterJS.empfehlung-ho.link.link
[3] https://enterjs.de/tickets.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_enterJS.empfehlung-ho.link.link
[4] https://www.deque.com/automated-accessibility-coverage-report
[5] https://www.deque.com/blog/deques-second-annual-axe-con-marks-the-year-of-accessibility/
[6] https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/
[7] https://adrianroselli.com/2023/01/comparing-manual-and-free-automated-wcag-reviews.html
[8] https://html5accessibility.com/stuff/2025/03/27/mind-the-wcag-automation-gap/
[9] https://developer.mozilla.org/en-US/docs/Web/API/Translator_and_Language_Detector_APIs
[10] https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/
[11] https://adrianroselli.com/2020/11/more-accessible-skeletons.html
[12] mailto:mai@heise.de

Copyright © 2026 Heise Medien