Die häufigsten Barrierefreiheitsfehler auf Websites sind Text mit zu wenig Kontrast, Bilder ohne Alt-Text, Formularfelder ohne Beschriftung, leere Links, leere Buttons und eine fehlende Sprachangabe. Das zeigt der WebAIM-Million-Bericht 2026, der die Startseiten von einer Million beliebter Websites automatisch testet. Laut diesem Bericht fallen 96 % aller gefundenen Fehler in diese sechs Kategorien.
Die gute Nachricht: Die meisten dieser Fehler behebst du mit ein paar Zeilen HTML oder einer anderen Arbeitsweise in deinem CMS. Dieser Artikel stellt die zehn häufigsten Fehler zusammen, mit dem zugehörigen WCAG-Kriterium und einer konkreten Lösung. Er gehört zu unserem vollständigen Leitfaden zur Barrierefreiheit von Websites.
Was sagt der WebAIM-Million-Bericht?
Der WebAIM-Million-Bericht ist ein jährlicher, automatischer Barrierefreiheitstest der Startseiten der eine Million beliebtesten Websites. Die Ausgabe 2026 basiert auf Messungen vom Februar 2026 mit dem WAVE-Tool von WebAIM, das auf Fehler gegen WCAG 2.2 Stufe A und AA prüft.
Die wichtigsten Zahlen aus dem Bericht:
- 95,9 % der Startseiten hatten automatisch erkennbare WCAG-Fehler, gegenüber 94,8 % im Jahr 2025.
- Im Schnitt standen 56,1 Fehler auf einer Startseite, gegenüber 51 im Jahr 2025.
- Die sechs häufigsten Fehlertypen sind laut WebAIM seit sieben Jahren dieselben.
| Fehler (WebAIM Million 2026) | Anteil der Startseiten 2026 | 2025 |
|---|---|---|
| Text mit zu geringem Kontrast | 83,9 % | 79,1 % |
| Fehlender Alt-Text bei Bildern | 53,1 % | 55,5 % |
| Formularfelder ohne Beschriftung | 51 % | 48,2 % |
| Leere Links | 46,3 % | 45,4 % |
| Leere Buttons | 30,6 % | 29,6 % |
| Fehlende Dokumentsprache | 13,5 % | 15,8 % |
Die Fehler 7 bis 10 in dieser Liste stammen aus anderen Messungen im selben Bericht: Überschriftenstruktur, vage Linktexte, ARIA-Nutzung und Skiplinks. WebAIM zählt sie nicht zu den Top sechs, aber sie wurden gemessen und betreffen viele Websites.
Eine Einschränkung, die WebAIM selbst macht: Automatische Tools finden nicht alle Fehler. Der Bericht schreibt, dass das Fehlen gefundener Fehler nicht bedeutet, dass eine Seite barrierefrei ist oder WCAG erfüllt. Die tatsächliche Lage ist also schlechter, als diese Zahlen zeigen.
1. Text mit zu wenig Farbkontrast
Zu geringer Kontrast ist der häufigste Barrierefreiheitsfehler: WebAIM fand ihn auf 83,9 % der Startseiten, mit durchschnittlich 34 Fällen pro Seite. Es geht um Text, dessen Farbe sich zu wenig vom Hintergrund abhebt.
- WCAG-Kriterium: 1.4.3 Contrast (Minimum), Stufe AA. Normaler Text braucht mindestens 4,5:1, großer Text (18 Punkt, oder 14 Punkt fett) mindestens 3:1, laut der WCAG-2.2-Spezifikation.
- Warum es wichtig ist: Menschen, die schlecht sehen, älter sind oder ihr Handy in der Sonne nutzen, können hellgrauen Text oder Text über einem Foto nicht lesen.
Die Lösung liegt in deinem Corporate Design und CSS, nicht im HTML. Wähle Textfarben, die mit einem Kontrastchecker mindestens 4,5:1 erreichen, und leg eine dunkle Ebene unter Text, der über einem Bild steht. Mehr zum Farbkontrast findest du im Glossar.
2. Bilder ohne Alt-Text
Ein fehlender Alt-Text ist der zweithäufigste Fehler: 53,1 % der Startseiten hatten mindestens ein Bild ohne alt-Attribut. Laut WebAIM fehlte bei 16,2 % aller Bilder ein Alt-Text, im Schnitt 10,8 pro Startseite.
- WCAG-Kriterium: 1.1.1 Non-text Content, Stufe A.
- Warum es wichtig ist: Ein Screenreader liest dann nichts vor, oder den Dateinamen. Bei einem verlinkten Bild weiß der Nutzer nicht, wohin der Link führt. WebAIM meldet, dass 45 % der Bilder ohne Alt-Text verlinkt waren.
Gib informativen Bildern eine kurze Beschreibung dessen, was sie in diesem Zusammenhang aussagen. Gib rein dekorativen Bildern ein leeres alt, damit ein Screenreader sie überspringt.
<!-- Informatives Bild -->
<img src="team.jpg" alt="Unser fünfköpfiges Support-Team am Empfang in Leipzig">
<!-- Verlinktes Bild: beschreib das Ziel des Links -->
<a href="/preise"><img src="preise-icon.svg" alt="Preise ansehen"></a>
<!-- Dekoratives Bild: leeres alt -->
<img src="wellenlinie.svg" alt="">
Ein guter Alt-Text hilft auch Suchmaschinen und KI-Systemen, deine Bilder zu verstehen, siehe Inhalte, die KI zitiert.
3. Formularfelder ohne Beschriftung
Ein Formularfeld ohne Beschriftung ist der dritthäufigste Fehler: 51 % der Startseiten hatten mindestens eines. Von allen Formularfeldern waren laut WebAIM 33,1 % nicht richtig beschriftet.
- WCAG-Kriterien: 1.3.1 Info and Relationships (A), 3.3.2 Labels or Instructions (A) und 4.1.2 Name, Role, Value (A).
- Warum es wichtig ist: Ein Screenreader sagt nur "Eingabefeld", ohne mitzuteilen, was du eingeben sollst. Ein Platzhalter verschwindet, sobald du tippst, sodass auch sehende Nutzer die Frage vergessen.
Verknüpfe mit for und id eine sichtbare Beschriftung mit jedem Feld. Ein Suchfeld mit nur einem Icon kann ein aria-label bekommen.
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email">
<!-- Suchfeld ohne sichtbare Beschriftung -->
<input type="search" name="q" aria-label="Website durchsuchen">
Für Bestellformulare und Checkouts geht der Artikel über barrierefreie Formulare und Checkout tiefer auf Fehlermeldungen und Pflichtfelder ein.
4. Leere Links
Ein leerer Link ist ein Link ohne Text, den ein Screenreader vorlesen kann. WebAIM fand leere Links auf 46,3 % der Startseiten. Meist geht es um ein Social-Media-Icon oder ein Logo ohne Alt-Text.
- WCAG-Kriterien: 2.4.4 Link Purpose (In Context), Stufe A, und 4.1.2 Name, Role, Value, Stufe A.
- Warum es wichtig ist: Der Nutzer hört nur "Link" und weiß nicht, wohin er führt.
<!-- Falsch: Icon ohne Text -->
<a href="https://www.linkedin.com/company/beispiel"><svg>…</svg></a>
<!-- Richtig: Text für den Screenreader, Icon ausgeblendet -->
<a href="https://www.linkedin.com/company/beispiel">
<svg aria-hidden="true" focusable="false">…</svg>
<span class="visually-hidden">Folge uns auf LinkedIn</span>
</a>
5. Leere Buttons
Ein leerer Button ist ein Button ohne zugänglichen Namen, und WebAIM fand ihn auf 30,6 % der Startseiten. Denk an ein Hamburger-Menü, ein Schließen-Kreuz oder einen Such-Button mit nur einem Icon.
- WCAG-Kriterium: 4.1.2 Name, Role, Value, Stufe A. Bei einem Bild als Button auch 1.1.1.
- Warum es wichtig ist: Wer den Button nicht sieht, weiß nicht, was er bewirkt, und traut sich nicht, ihn zu drücken.
<button type="button" aria-label="Menü öffnen" aria-expanded="false">
<svg aria-hidden="true" focusable="false">…</svg>
</button>
6. Fehlende Dokumentsprache
Eine Seite ohne Sprachangabe sagt dem Browser nicht, in welcher Sprache der Text steht. Laut WebAIM fehlte sie auf 13,5 % der Startseiten.
- WCAG-Kriterium: 3.1.1 Language of Page, Stufe A. Für Passagen in einer anderen Sprache: 3.1.2 Language of Parts, Stufe AA.
- Warum es wichtig ist: Ein Screenreader liest deutschen Text dann mit englischer Aussprache vor, was oft unverständlich ist.
<html lang="de">
…
<p>Unser Slogan lautet <span lang="en">built for speed</span>.</p>
</html>
7. Eine unaufgeräumte Überschriftenstruktur
Überschriften sind für Screenreader-Nutzer das Inhaltsverzeichnis einer Seite, und auf vielen Websites stimmt es nicht. WebAIM zählte übersprungene Überschriftenebenen, etwa einen Sprung von H2 auf H4, auf 41,8 % der Startseiten. Auf 18,1 % stand mehr als eine H1, und 7,5 % hatten überhaupt keine Überschriften.
- WCAG-Kriterien: 1.3.1 Info and Relationships (A) und 2.4.6 Headings and Labels (AA).
- Warum es wichtig ist: WebAIM schreibt, dass Überschriften das wichtigste Mittel sind, mit dem Screenreader-Nutzer durch Inhalte navigieren.
Eine übersprungene Ebene ist für sich genommen nicht immer ein WCAG-Fehler, aber sie macht die Struktur unklar. Verwende Überschriften in der richtigen Reihenfolge und wähle die Ebene nach der Struktur, nicht nach der Schriftgröße. Fett gedruckter Text, der wie eine Überschrift aussieht, im Code aber keine ist, ist dagegen ein Fehler nach 1.3.1.
8. Vage Linktexte
Ein vager Linktext wie "hier klicken", "mehr" oder "weiter" sagt nichts über das Ziel des Links aus. WebAIM fand solche Linktexte auf 15,2 % der Startseiten, mit durchschnittlich 5,3 Fällen pro Seite.
- WCAG-Kriterium: 2.4.4 Link Purpose (In Context), Stufe A.
- Warum es wichtig ist: Screenreader-Nutzer lassen sich oft eine Liste aller Links vorlesen. Zehnmal "weiterlesen" ist dann unbrauchbar.
Schreib das Ziel in den Linktext: "Öffnungszeiten ansehen" statt "hier klicken". Das ist der Fehler, den du als Content-Ersteller am leichtesten vermeidest.
9. Falsch eingesetztes ARIA
WAI-ARIA ist eine Reihe von HTML-Attributen, die assistiven Technologien zusätzliche Informationen liefert, aber falsche Verwendung macht eine Seite gerade schlechter. WebAIM zählte im Schnitt mehr als 133 ARIA-Attribute pro Startseite. Seiten mit ARIA hatten durchschnittlich 59,1 Fehler, gegenüber 42 auf Seiten ohne.
WebAIM betont, dass dies ein Zusammenhang ist und kein Beweis, dass ARIA die Fehler verursacht; Seiten mit ARIA sind auch komplexer. Konkret aber: Von den ARIA-Menüs (role="menu") verursachten 22 % Barrierefreiheitsprobleme durch fehlenden Code oder fehlende Tastaturbedienung.
- WCAG-Kriterium: meist 4.1.2 Name, Role, Value, Stufe A.
- Lösung: Verwende zuerst normale HTML-Elemente wie
<button>,<nav>und<a>. Die haben die richtige Rolle und Tastaturbedienung schon eingebaut. Ergänze ARIA nur dort, wo HTML nicht ausreicht.
10. Ein fehlender oder kaputter Skiplink
Ein Skiplink ist ein Link oben auf der Seite, mit dem Tastaturnutzer die Navigation überspringen und direkt zum Inhalt gelangen. Laut WebAIM hatten 17,1 % der Startseiten einen Skiplink, und jeder zehnte davon funktionierte nicht.
- WCAG-Kriterium: 2.4.1 Bypass Blocks, Stufe A. Ein Skiplink ist ein gängiger Weg, das zu erfüllen; Überschriften und Landmarks wie
<main>helfen auch. - Warum es wichtig ist: Ohne Skiplink muss ein Tastaturnutzer auf jeder Seite erneut durch das gesamte Menü tabben.
<body>
<a href="#inhalt" class="skiplink">Zum Inhalt springen</a>
<header>…</header>
<main id="inhalt">…</main>
</body>
Versteck den Skiplink nicht mit display: none, denn dann funktioniert er nicht. Lass ihn sichtbar werden, sobald er den Fokus bekommt.
Welche Fehler finden automatische Tools und welche nicht?
Automatische Tools erkennen, ob etwas fehlt, aber selten, ob etwas stimmt. Dieser Unterschied bestimmt, wie viel Handarbeit nach einem Scan übrig bleibt.
| Fehler | Automatisch auffindbar | Was manuell bleibt |
|---|---|---|
| Zu geringer Kontrast | Nur mit einer gerenderten Seite | Text über Bildern, Verläufe und Hover-Zustände |
| Fehlender Alt-Text | Ja | Ob der Alt-Text das Bild gut beschreibt |
| Felder ohne Beschriftung | Ja | Ob die Beschriftung verständlich ist |
| Leere Links und Buttons | Ja | Ob der Name die Funktion gut beschreibt |
| Fehlende Dokumentsprache | Ja | Ob die eingestellte Sprache stimmt |
| Überschriftenstruktur | Teilweise, etwa übersprungene Ebenen | Ob Überschriften den Inhalt gut beschreiben |
| Vage Linktexte | Teilweise, bekannte Wörter wie "hier klicken" | Ob ein Link im Kontext verständlich ist |
| ARIA | Technische Fehler in Attributen | Ob die Bedienung mit der Tastatur funktioniert |
| Skiplink | Ob er vorhanden ist | Ob er sichtbar wird und zum Inhalt springt |
Der Farbkontrast verdient besondere Aufmerksamkeit. Um Kontrast zu messen, muss ein Tool wissen, welche Farbe Text und Hintergrund tatsächlich bekommen, inklusive Stylesheets, Bildern und Ebenen. Das erfordert eine echte Darstellung der Seite. Ein Test, der nur das HTML analysiert, kann Kontrast deshalb nicht zuverlässig messen. Flowproof meldet Kontrast aus diesem Grund als manuell zu prüfen, statt ein Ergebnis zu liefern, das nicht stimmt.
Wie du automatisches und manuelles Testen kombinierst, liest du in Barrierefreiheit von Websites testen. Die Kriterien selbst werden in WCAG 2.2 erklärt beschrieben.
So prüfst du das auf deiner eigenen Website
Mit diesen Schritten spürst du die zehn Fehler auf deiner eigenen Website auf:
- Lass einen automatischen Test laufen auf deiner Startseite, einer Landingpage, einer Produktseite und deinem wichtigsten Formular. Er findet fehlende Alt-Texte, Beschriftungen, leere Links und Buttons und die Dokumentsprache.
- Miss den Kontrast mit einem Kontrastchecker, vor allem bei hellen Farbtönen, Markenfarben und Text über Fotos.
- Sieh dir deine Überschriftenstruktur an mit einer Browsererweiterung, die die Überschriften als Liste zeigt, und prüfe, ob sich diese Liste wie ein Inhaltsverzeichnis liest.
- Lies deine Linktexte losgelöst vom umgebenden Text und ersetze jedes "hier klicken" oder "weiterlesen".
- Tab dich durch die Seite nur mit der Tastatur: Funktioniert der Skiplink, siehst du den Fokus und kannst du Menüs öffnen und schließen?
- Prüfe die Alt-Texte in deiner Mediathek auf Inhalt, nicht nur auf Vorhandensein.
Die Barrierefreiheitsprüfung von Flowproof ist in den kostenpflichtigen Tarifen Pro und Business enthalten. Sie testet mit axe-core auf WCAG 2.0, 2.1 und 2.2 Stufe A und AA, zeigt für jeden Befund das Erfolgskriterium, die Stufe und den Schweregrad und prüft auch, ob du einen Skiplink und einen Link zu deiner Barrierefreiheitserklärung hast. Du kannst kostenlos ein Konto anlegen und später upgraden.