Die 12 häufigsten Barrierefreiheits-Fehler auf Websites: WCAG-Fehler erkennen und beheben

Von Manuel Hack, ihp media · Aktualisiert am 21. Juni 2026

Barrierefreiheit scheitert auf den meisten Websites nicht an komplizierten Randproblemen, sondern an wenigen, gut bekannten Fehlern. Der WebAIM Million Report analysiert jedes Jahr automatisch eine Million Startseiten. Das Ergebnis für 2026: durchschnittlich 56,1 messbare Barrieren pro Seite, und 96 % davon gehören zu sechs Fehlertypen. Die folgenden zwölf Fehler decken die verbreiteten Muster ab, jeweils mit dem zugehörigen WCAG-Kriterium und konkretem Lösungsweg.

Warum dieselben Fehler immer wieder auftauchen

Der Hauptgrund ist struktureller Natur: Barrierefreiheit wird in vielen Projekten erst nachträglich bedacht, nicht von Anfang an eingeplant. Das Ergebnis sind technische Altlasten, die sich mit jeder neuen Seite und jedem Redesign weiter aufschichten. Dazu kommt ein hartnäckiges Missverständnis über Prüfwerkzeuge: Ein grüner Lighthouse-Score bedeutet nicht, dass eine Website barrierefrei ist. Automatische Tools erkennen zuverlässig nur einen Teil der tatsächlichen Probleme. Den Rest findet man erst bei einem manuellen Test oder einem Durchgang mit einem Screenreader.

Die 12 häufigsten Fehler im Überblick

Die folgende Tabelle zeigt alle zwölf Fehler mit dem zugehörigen WCAG-Kriterium, der typischen Folge und einem konkreten Lösungsweg.

1. Zu geringer Farbkontrast

Auf 83,9 % aller analysierten Startseiten gibt es Textstellen, die den WCAG-Mindestwert für Kontrast verfehlen. Das ist der häufigste Fehler, seit WebAIM den Report vor sieben Jahren erstmals veröffentlicht hat. Die WCAG 2.2 Kriterium 1.4.3 verlangt mindestens 4,5:1 für normalen Text, für großen Text (ab 18 Punkt oder ab 14 Punkt fett) genügen 3:1. Grauer Hilfetext auf weißem Hintergrund, pastellfarbene Überschriften oder dünne Schriftschnitte in kleiner Größe fallen regelmäßig durch. Werkzeuge wie Axe und WAVE messen das automatisch. Wie Sie Kontraste richtig messen, belegen und dokumentieren, zeigt der Artikel Farbkontrast nach WCAG richtig prüfen.

2. Fehlende oder nichtssagende Alternativtexte

16,2 % aller Bilder auf den analysierten Startseiten haben keinen Alternativtext. Noch häufiger ist das gegenteilige Problem: Texte wie „image001.jpg“, „Foto“, „Grafik“ oder leere Strings, wo eigentlich eine Beschreibung stehen sollte. Ein guter Alternativtext beschreibt den Bildinhalt so, dass jemand ohne Sicht denselben Informationsgewinn hat. Rein dekorative Bilder, Trennlinien, Hintergrundmuster, Füllbilder ohne eigenen Informationswert, erhalten ein leeres alt="", damit Screenreader sie korrekt überspringen. WCAG-Grundlage ist Kriterium 1.1.1, Stufe A. Was ein guter Alt-Text können muss und wo die Grenze zwischen informativem und dekorativem Bild liegt, erklärt der Artikel Gute Alternativtexte schreiben.

3. Keine Tastaturbedienbarkeit

Alle interaktiven Elemente einer Website, Menüs, Formulare, Schaltflächen, Dialoge, müssen per Tabulator-Taste erreichbar und per Enter oder Leertaste auslösbar sein. In der Praxis sind es oft klickbare div– oder span-Elemente, die optisch wie Buttons wirken, aber für Tastatur- und Screenreader-Nutzer stumm bleiben. Ein div ist nicht fokussierbar und hat keine semantische Rolle. Wer es als Button einsetzt, muss tabindex="0", role="button" und Tastatur-Event-Handler manuell ergänzen. Einfacher ist ein echtes <button>-Element, das das alles von Haus aus mitbringt. WCAG-Grundlage: Kriterium 2.1.1, Stufe A. Den vollständigen Tastaturbedierungs-Test für die eigene Website zeigt Website-Barrierefreiheit selbst testen.

4. Kein sichtbarer Fokusrahmen

Browser zeigen standardmäßig einen Rahmen um das gerade per Tastatur angewählte Element. Viele Designs entfernen ihn mit outline: none oder outline: 0, weil er optisch stört. Das ist eine der gravierendsten Barrieren für alle, die auf Tastaturnavigation angewiesen sind, denn sie verlieren jede Orientierung auf der Seite. Die Lösung ist kein Kompromiss zwischen Optik und Funktion, sondern ein gestalteter Fokusring, der zum Design passt. Mit :focus-visible lässt sich der Fokus nur bei Tastaturnavigation sichtbar machen, nicht beim Klick mit der Maus. WCAG 2.2 Kriterium 2.4.7 fordert sichtbaren Fokus auf Stufe AA; mit WCAG 2.2 kommt das verschärfte Kriterium 2.4.13 (Fokus-Darstellung) hinzu, das Kontrast und Mindestgröße des Fokusindikators regelt (Stufe AAA).

5. Formularfelder ohne verknüpfte Labels

51 % aller analysierten Startseiten haben Formularfelder ohne korrekte Labels, das ist der dritte Platz in der WebAIM-Rangliste. Ein Eingabefeld ohne programmatisch verknüpftes <label> ist für Screenreader-Nutzer nicht interpretierbar. Platzhaltertexte (placeholder) sind kein Ersatz: Sie verschwinden, sobald der Nutzer zu tippen beginnt, und werden von einigen Screenreadern gar nicht als Feldbeschriftung erkannt. Jedes Feld braucht entweder ein sichtbares <label for="feld-id"> oder ein aria-label-Attribut. Wenn bereits ein sichtbares Textelement als Beschriftung dient, ist aria-labelledby die sauberere Wahl: Es verweist auf die ID des vorhandenen Elements statt den Text zu duplizieren. WCAG 2.2 Kriterium 3.3.2, Stufe AA.

6. Videos ohne Untertitel

Videoinhalte ohne Untertitel schließen gehörlose und schwerhörige Nutzer aus. Sie treffen auch alle anderen, die in einer lauten Umgebung oder ohne Kopfhörer schauen, und das ist eine größere Gruppe als gemeinhin angenommen. Die WCAG 2.2 Kriterium 1.2.2 fordert für vorab aufgezeichnete Videos synchrone Untertitel auf Konformitätsstufe A. Automatisch generierte Untertitel, etwa von YouTube, taugen als Ausgangspunkt, müssen aber manuell geprüft und korrigiert werden, besonders bei Eigennamen, Fachbegriffen und schnellem Sprechtempo. Ausführlicher behandeln wir das Thema in Barrierefreie Videos und PDFs.

7. Seitenstruktur ohne semantische Überschriften

Viele Seiten nutzen Überschriften-Tags für optische Größen, nicht für inhaltliche Gliederung. Eine H2 wird gesetzt, weil die Schrift groß wirken soll, nicht weil sie eine Hauptsektion einleitet. Für Screenreader entsteht daraus eine Dokumentstruktur ohne Sinn. Screenreader-Nutzer navigieren sehr häufig über die Überschriften-Liste eines Dokuments, ähnlich wie ein sehender Leser das Inhaltsverzeichnis nutzt. Eine lückenlose Hierarchie aus H1 (genau einmal), H2 (Hauptsektionen), H3 (Unterabschnitte) spiegelt den Inhalt wider, unabhängig vom visuellen Design. Die technische Grundlage ist WCAG 2.2 Kriterium 1.3.1, Stufe A. Ein häufiger Fehler in WordPress/Divi: Das Theme setzt ein H1 fürs Logo, ein weiteres für den Seitentitel, und der erste sichtbare Abschnitt beginnt mit einer H3.

8. Fehlende Sprachauszeichnung im HTML

Das lang-Attribut im <html>-Tag teilt Screenreadern mit, in welcher Sprache der Inhalt verfasst ist, damit die Sprachausgabe korrekt klingt. Fehlt es, kann ein deutschsprachiger Text mit englischer Aussprache und Betonung vorgelesen werden, kaum verständlich. 13,5 % aller analysierten Startseiten haben diese Information laut WebAIM nicht gesetzt. Die Korrektur ist drei Zeichen: lang="de" ins <html>-Tag. Bei fremdsprachigen Abschnitten wird das Attribut zusätzlich auf Block-Ebene gesetzt (<p lang="en">). WCAG-Grundlage: Kriterium 3.1.1, Stufe A.

9. PDFs ohne Barrierefreiheits-Tags

Herunterladbare Dokumente werden in Barrierefreiheits-Prüfungen häufig vergessen. PDFs, die aus Word oder InDesign ohne entsprechende Export-Einstellungen erzeugt wurden, haben keine Tags, keine definierten Überschriften und keine Lesereihenfolge. Für Screenreader sind sie Rauschen. Microsoft Word bietet unter „Datei > Informationen > Auf Probleme überprüfen > Barrierefreiheit prüfen“ eine eigene Analyse vor dem Export. Adobe Acrobat Pro hat ein eigenes Barrierefreiheits-Check-Werkzeug. Noch zuverlässiger ist eine gut strukturierte HTML-Version als Ergänzung zu einem nicht barrierefreien PDF. Das BFSG erfasst PDFs ausdrücklich, wenn sie Teil der angebotenen Dienstleistung sind. Mehr dazu im Artikel Barrierefreie Videos und PDF.

10. Zeitlimits ohne Verlängerungsoption

Formulare mit automatischem Timeout oder ablaufender Sitzung müssen Nutzern die Möglichkeit geben, die Zeit zu verlängern oder die Begrenzung abzuschalten. Betroffen sind vor allem Anfrageformulare mit CAPTCHA und Buchungsstrecken, bei denen langsames Ausfüllen zum Datenverlust führen kann. Das betrifft Menschen, die mehr Zeit zum Tippen brauchen, aber auch jemanden, der ein langes Formular unterbricht, um einen Wert nachzuschlagen. WCAG 2.2 Kriterium 2.2.1, Stufe A, verlangt: Die Zeitvorgabe muss deaktivierbar, anpassbar oder verlängerbar sein, und die Warnung muss mindestens 20 Sekunden vor Ablauf erscheinen.

11. Fehlende Skip-Links

Auf Websites mit umfangreichem Hauptmenü tippen sich Tastaturnutzer ohne Skip-Link durch jeden einzelnen Menüpunkt, bevor sie den eigentlichen Inhalt erreichen. Bei zehn Navigationspunkten und fünf Untermenüs kann das 50 Tab-Drücke bedeuten, auf jeder einzelnen Seite neu. Ein „Zum Inhalt springen“-Link am Seitenanfang, der bei Tastaturfokus sichtbar wird und direkt zum Hauptinhalt springt (id="main"), ist technisch schnell umgesetzt. In WordPress lässt er sich als mu-plugin oder per Child-Theme-Hook einbetten. WCAG 2.2 Kriterium 2.4.1, Stufe A.

12. Dynamische Inhalte ohne ARIA-Live-Regionen

Wenn Inhalte nachgeladen werden, ein Filter greift, eine Fehlermeldung erscheint, ein Warenkorb-Zähler ändert sich, ohne dass die Seite vollständig neu lädt, erfährt ein Screenreader-Nutzer davon nichts. ARIA-Live-Regionen lösen das: aria-live="polite" kündigt Änderungen an, sobald der Nutzer nicht aktiv mit einem Element interagiert. aria-live="assertive" unterbricht sofort, was nur für echte Fehlermeldungen sinnvoll ist. WCAG 2.2 Kriterium 4.1.3, Stufe AA, fordert, dass Statusmeldungen programmatisch bestimmbar sind, ohne dass der Fokus auf das Element gesetzt werden muss. Für WooCommerce-Shops ist das besonders relevant: Warenkorb-Updates, Suchvorschläge und Validierungsmeldungen im Checkout laufen alle ohne Seitenneuladen ab.

Was das BFSG konkret bedeutet

Das Barrierefreiheitsstärkungsgesetz setzt die EU-Richtlinie 2019/882 in deutsches Recht um. Für Websites gilt: Die technische Referenz ist die EN 301 549, die auf die WCAG 2.1 AA verweist, die aktuell gültige WCAG 2.2 bringt bei den zwölf hier genannten Fehlern keine wesentlichen Änderungen, da diese Kriterien in beiden Versionen gelten. Kleinstunternehmen mit weniger als zehn Beschäftigten und einem Jahresumsatz unter zwei Millionen Euro sind nur bei Dienstleistungen ausgenommen, nicht bei Waren-Onlineshops. Wer Verbraucherverträge online abschließt, sollte die Einordnung nicht pauschal annehmen, ohne sie geprüft zu haben. Bei Verstößen sieht § 37 BFSG Bußgelder bis zu 100.000 Euro vor. Den vollständigen BFSG-Überblick für Onlineshops gibt der Artikel BFSG und Onlineshop: Was Händler wissen müssen.

Die drei wichtigsten Prüfwerkzeuge

Automatische Werkzeuge sind ein guter Einstieg, aber kein Ersatz für manuelle Prüfung. Sie erkennen zuverlässig Kontrastwerte, fehlende Alt-Texte und offensichtliche Struktur-Fehler. Was sie nicht beurteilen: ob ein Alt-Text inhaltlich sinnvoll ist, ob ein Formular unter realen Bedingungen mit einem Screenreader bedienbar bleibt, und ob die Lesereihenfolge im Quelltext der sichtbaren Reihenfolge entspricht.

Für einen schnellen Selbsttest ohne Installation zeigt die W3C-Vorprüfungscheckliste die wichtigsten manuellen Prüfschritte. Eine strukturierte 30-Minuten-Prüfung mit konkreten Schritten zeigt der Artikel Website-Barrierefreiheit selbst testen.

Praxisbeispiel: Was ein echter Audit zeigt

In einem Projekt prüften wir eine WordPress-Website eines mittelständischen Dienstleisters mit Lighthouse, Axe und einem manuellen Tastatur-Durchgang. Das automatische Prüfwerkzeug meldete 11 Fehler. Die manuelle Prüfung fand weitere 24. Die häufigsten:

• Das Navigationsmenü war per Tastatur nicht vollständig bedienbar, Dropdown-Untermenüs ließen sich öffnen, aber nicht durch Pfeiltasten steuern.
• Alle Produktbilder hatten Alt-Texte, die identisch mit dem Dateinamen waren: „foto-team-1.jpg“, „foto-team-2.jpg“.
• Drei Kontaktformular-Felder hatten sichtbare Beschriftungen als gestaltete div-Elemente, aber keine programmatische Verknüpfung. Ein Screenreader las die Felder als „Bearbeitungsfeld“ ohne Kontext vor.
• Der Farbkontrast des Haupttextes war 4,6:1, knapp über dem Mindestwert. Die grauen Hilfstexte unter den Formularen lagen bei 2,8:1.

Kein automatisches Werkzeug hatte die Navigations-Bedienbarkeit und die falsch verknüpften Labels gefunden. Axe meldete den Kontrast der Hilfstexte korrekt, den knapp grenzwertigen Haupttext aber nicht als Fehler. Das zeigt: Ein grüner Score bedeutet nicht barrierefrei, sondern nur keine automatisch messbaren Fehler mehr.

Sofort-Checkliste

Diese Punkte können Sie heute ohne spezielle Kenntnisse selbst prüfen. Tabulator-Taste statt Maus benutzen ist der wichtigste einzelne Test.

• Lässt sich die Seite komplett ohne Maus, nur mit der Tastatur bedienen?
• Ist beim Durchtabben immer sichtbar, welches Element gerade aktiv ist?
• Haben alle inhaltlich relevanten Bilder einen sinnvollen Alt-Text?
• Sind Fließtext, Überschriften und Buttons kontrastreich genug (mindestens 4,5:1)?
• Hat jedes Formularfeld ein sichtbares, programmatisch verknüpftes Label?
• Gibt es auf jeder Seite einen Skip-Link zum Hauptinhalt?
• Ist im HTML-Tag die Seitensprache angegeben (lang="de")?
• Haben Videos Untertitel oder Transkripte?
• Sind herunterladbare PDFs getaggt und screenreader-lesbar?
• Werden dynamische Inhalte (Fehler, Suchergebnisse, Warenkorbänderungen) per ARIA-Live angekündigt?
• Folgen Überschriften einer lückenlosen Hierarchie (H1 > H2 > H3)?
• Haben Formulare mit Zeitlimit eine Verlängerungsmöglichkeit?

Häufige Fragen

Gilt das BFSG auch für kleine Unternehmen?

Das hängt von Unternehmensgröße und Art der digitalen Leistung ab. Kleinstunternehmen mit weniger als zehn Beschäftigten und einem Jahresumsatz unter zwei Millionen Euro können bei Dienstleistungen von bestimmten Pflichten ausgenommen sein. Wer aber einen Onlineshop betreibt oder digitale Dienstleistungen an Verbraucher verkauft, sollte die Einordnung nicht ohne Prüfung als gegeben annehmen.

Reicht es, eine Overlay-Lösung zu installieren?

Nein. Browser-Plugins oder JavaScript-Overlays, die Barrierefreiheit automatisch nachrüsten sollen, sind kein vollständiger Ersatz für sauber umgesetzten Code. Sie lindern einzelne Symptome, erzeugen häufig neue Probleme und werden von führenden Behindertenverbänden ausdrücklich abgelehnt. Vor der Marktüberwachungsstelle der Länder für die Barrierefreiheit (MLBF) als Nachweis gelten sie nicht.

Wie oft sollte man die Barrierefreiheit prüfen?

Spätestens nach jeder größeren Überarbeitung, nach jedem Update, das Formular- oder Navigationsstrukturen verändert, und bei der Einführung neuer Seiten oder Funktionen. Jedes neue Plugin kann neue Barrieren mitbringen. Ein einmal erreichter Zustand bleibt nicht dauerhaft erhalten.

Welche WCAG-Stufe ist für Unternehmen relevant?

Für die meisten rechtlichen Anforderungen ist die Konformitätsstufe AA der Maßstab. Die technische Referenz des BFSG, die EN 301 549, orientiert sich für Websites und Apps ebenfalls an AA. Stufe AAA ist für die meisten Angebote nicht vollständig erreichbar und auch nicht gefordert.

Finden automatische Tools alle Probleme?

Nein. Der WebAIM Million Report schätzt, dass automatische Tests nur einen Teil der tatsächlichen WCAG-Verstöße erkennen. Ob ein Alt-Text inhaltlich korrekt ist, ob ein Dialog den Fokus fangt oder ob ein Formular mit einem Screenreader bedienbar ist, kann kein automatisches Werkzeug beurteilen. Ein manueller Test ist immer nötig.

Was ist der eine wichtigste erste Schritt?

Den Tastatur-Test: Laden Sie Ihre Seite, legen Sie die Maus weg und navigieren Sie ausschließlich mit der Tabulator-Taste. Kommt der Fokus irgendwo zum Erliegen, verliert er die Sichtbarkeit oder erreicht er ein Element nicht, haben Sie einen kritischen Mangel gefunden, der heute behoben werden kann.