Häufige Barrierefreiheitsfehler vermeiden

Warum dieselben Barrierefreiheitsprobleme immer wieder auftauchen

Die meisten Barrieren sind nicht exotisch. Jahr für Jahr fördern automatisierte und manuelle Audits dieselbe kurze Liste von Fehlern zutage: fehlender Alternativtext, geringer Kontrast, unbeschriftete Formularfelder, Tastaturfallen und kaputte Struktur. Sie kehren wieder, weil sie unbemerkt eingeführt werden — ein Entwickler veröffentlicht eine neue Komponente, ein Marketer lädt ein Bild hoch, ein Designer wählt eine Markenfarbe — und nichts im normalen Arbeitsablauf weist auf das Problem hin. Das visuelle Ergebnis sieht für jemanden mit Maus und scharfen Augen in Ordnung aus, also geht die Barriere in Produktion.

Dieser Katalog geht die häufigsten WCAG 2.2-Verstöße durch, die wir in echten Audits sehen. Zu jedem finden Sie, warum er wichtig ist, wen er betrifft, das relevante Erfolgskriterium und eine konkrete Vorher/Nachher-Korrektur. Zusammen machen diese Probleme die überwältigende Mehrheit der Barrieren aus, die Menschen mit Behinderungen ausschließen — und die überwältigende Mehrheit der rechtlichen Beschwerden, die nach dem European Accessibility Act, dem ADA und Section 508 eingereicht werden.

Eines sollten Sie vor der Liste klarstellen: Automatisierte Tools können nicht alle diese Probleme finden. Unabhängige Forschung zeigt durchweg, dass selbst die besten Scanner zuverlässig nur 30–40 % der WCAG-Probleme erkennen. Sie sind hervorragend darin, fehlende Alt-Attribute, programmatische Kontrastfehler und fehlende Formularbeschriftungen zu finden, aber sie können nicht beurteilen, ob ein Alternativtext zutreffend ist, ob die Fokusreihenfolge logisch ist oder ob ein benutzerdefiniertes Widget tatsächlich mit einem Screenreader funktioniert. Deshalb kombiniert jedes glaubwürdige Programm Scans mit manueller Prüfung. Unsere Software zum Scannen der Barrierefreiheit übernimmt die automatisierbare Ebene; manuelle Audits und Audits durch Menschen mit Behinderungen decken den Rest ab.

Eine schnelle Möglichkeit, Ihren eigenen Ausgangspunkt zu finden, bevor Sie weiterlesen: Betrachten Sie die Seite mit deaktivierten Bildern, lesen Sie jedes Wort als einen unstrukturierten Absatz und versuchen Sie, jede Aufgabe nur mit der Tastatur zu erledigen. Überall dort, wo das Erlebnis zusammenbricht, haben Sie eine Barriere gefunden.

Wahrnehmbar: Inhalte, die Menschen nicht sehen oder lesen können

Fehlender oder ungenauer Alternativtext für Bilder

Wen es betrifft: blinde oder sehbehinderte Menschen, die Screenreader nutzen; alle mit langsamer Verbindung, bei denen Bilder nicht geladen werden.

WCAG-Kriterium: 1.1.1 Nicht-Text-Inhalt (Level A).

Bilder ohne alt-Attribut sind für assistive Technologien unsichtbar — der Nutzer weiß möglicherweise nicht einmal, dass das Bild existiert. Schlimmer als ein fehlendes Attribut ist ein ungenaues: Dateinamen wie IMG_4821.jpg, allgemeine Wörter wie „Bild” oder mit Keywords vollgestopfte Zeichenketten führen den Zuhörer aktiv in die Irre.

Die Regel ist einfach, aber situationsabhängig. Informative Bilder benötigen eine prägnante Beschreibung ihrer Bedeutung, nicht ihres Aussehens. Dekorative Bilder, die nichts beitragen, sollten ein leeres alt="" tragen, damit Screenreader sie überspringen. Funktionale Bilder — ein Symbol, das als Schaltfläche dient — müssen die Aktion beschreiben, nicht das Bild. Komplexe Visualisierungen wie Diagramme benötigen einen kurzen Alternativtext sowie eine längere Textentsprechung in der Nähe.

<!-- Before: useless, misleading -->
<img src="chart-final-v2.png">

<!-- After: meaningful for an informative image -->
<img src="chart-final-v2.png"
     alt="Revenue grew 24% between Q1 and Q4 2025">

<!-- After: decorative image, correctly hidden -->
<img src="divider-flourish.svg" alt="">

Automatisierte Tools erkennen das Fehlen von Alternativtext sofort. Sie können Ihnen nicht sagen, ob der Text korrekt ist — das erfordert einen Menschen, der die Seite im Kontext liest.

Unzureichender Farbkontrast

Wen es betrifft: Menschen mit Sehbehinderung, Farbenblindheit oder altersbedingtem Sehverlust; alle, die einen Bildschirm in hellem Sonnenlicht nutzen.

WCAG-Kriterium: 1.4.3 Kontrast (Minimum), Level AA; sowie 1.4.11 Nicht-Text-Kontrast für UI-Komponenten.

WCAG 2.2 verlangt ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (etwa 18 pt oder 14 pt fett). Interface-Komponenten und bedeutungstragende Grafiken — Eingabefeldränder, Fokusindikatoren, zustandsanzeigende Symbole — müssen 3:1 gegenüber ihrer Umgebung erreichen. Kontrastfehler gehören zu den häufigsten Problemen, die in jedem groß angelegten Audit gefunden werden, und sie werden fast immer in der Designphase eingeführt.

/* Before: light gray on white = 2.8:1, fails AA */
.helper-text { color: #9a9a9a; background: #ffffff; }

/* After: 4.6:1, passes AA */
.helper-text { color: #717171; background: #ffffff; }

Testen Sie die gesamte Farbpalette, nicht nur den Fließtext: Platzhaltertext, deaktivierte Zustände, die dennoch lesbar sein müssen, Fehlermeldungen und Text über Fotos sind häufige Übeltäter. Verlassen Sie sich nie allein auf Farbe, um Bedeutung zu vermitteln (1.4.1) — ein roter Rand an einem ungültigen Feld muss mit Text oder einem Symbol kombiniert werden.

Automatisch abspielende Medien und Bewegung

Wen es betrifft: Menschen mit Gleichgewichtsstörungen, Aufmerksamkeits- oder kognitiven Behinderungen, Screenreader-Nutzer, deren Audioausgabe übertönt wird, und alle in einem ruhigen, geteilten Raum.

WCAG-Kriterien: 1.4.2 Audiosteuerung (Level A), 2.2.2 Pausieren, Stoppen, Ausblenden (Level A), 2.3.1 Dreimaliges Blitzen (Level A) und 2.3.3 Animation durch Interaktionen (Level AAA).

Audio oder Video, das länger als drei Sekunden automatisch abgespielt wird, muss eine offensichtliche Möglichkeit zum Pausieren oder Stummschalten bieten. Bewegte, blinkende oder sich automatisch aktualisierende Inhalte, die länger als fünf Sekunden dauern — Karussells, animierte Banner, Lauftexte — benötigen eine zugängliche Pausensteuerung. Inhalte, die mehr als dreimal pro Sekunde blitzen, können Anfälle auslösen und müssen vollständig vermieden werden. Respektieren Sie die prefers-reduced-motion-Einstellung des Nutzers, um nicht wesentliche Animationen abzuschwächen.

/* After: honour the user's OS-level motion preference */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Bedienbar: Dinge, die Menschen nicht nutzen können

Tastaturunzugänglichkeit und Tastaturfallen

Wen es betrifft: Menschen mit motorischen Behinderungen, die keine Maus nutzen können, Screenreader-Nutzer (die per Tastatur navigieren) und Menschen, die Schaltgeräte oder Sprachsteuerung nutzen.

WCAG-Kriterien: 2.1.1 Tastatur (Level A) und 2.1.2 Keine Tastaturfalle (Level A).

Jede Interaktion — Links, Schaltflächen, Formularfelder, Menüs, Modale, Datumsauswahlfelder, Drag-and-drop — muss vollständig allein mit der Tastatur bedienbar sein. Die schädlichste Variante ist die Tastaturfalle: Der Fokus gelangt in eine Komponente (oft ein Modal oder ein eingebettetes Widget) und kommt nicht mehr heraus, wodurch der Nutzer auf der Seite gestrandet ist. Selbst gebaute Widgets sind die üblichen Übeltäter, weil native Elemente wie <button> und <a> standardmäßig tastaturbedienbar sind, während <div>-basierte Nachbildungen es nicht sind.

<!-- Before: not focusable, not operable by keyboard -->
<div class="btn" onclick="submit()">Submit</div>

<!-- After: native element, free keyboard support -->
<button type="submit">Submit</button>

Gehen Sie Ihre Schlüsselabläufe nur mit Tab, Umschalt+Tab, Pfeiltasten, Enter, Leertaste und Escape durch. Stellen Sie sicher, dass sich der Fokus immer vorwärts und aus jeder Komponente heraus bewegen kann, dass Escape Overlays schließt und dass nichts einen Zeiger erfordert. Unser Dienst zur Screenreader-Bewertung testet genau diese Abläufe so, wie echte Nutzer assistiver Technologien sie erleben.

Fehlende oder unsichtbare Fokusindikatoren und unlogische Fokusreihenfolge

Wen es betrifft: sehende Tastaturnutzer, sehbehinderte Nutzer und alle, die den Überblick verloren haben, wo sie sich auf der Seite befinden.

WCAG-Kriterien: 2.4.7 Fokus sichtbar (Level A) und 2.4.3 Fokusreihenfolge (Level A); 2.4.11 Fokus nicht verdeckt (Level AA) in WCAG 2.2.

Ein häufiger „aufräumender” Fehler ist das Entfernen des standardmäßigen Fokusrings des Browsers mit outline: none, ohne ihn jemals zu ersetzen. Tastaturnutzer haben keine Ahnung, welches Element aktiv ist. Ebenso schädlich ist eine Fokusreihenfolge, die nicht der visuellen und logischen Lesereihenfolge folgt — typischerweise verursacht durch positive tabindex-Werte oder durch eine DOM-Reihenfolge, die vom dargestellten Layout abweicht.

/* Before: focus ring deleted, keyboard users lost */
:focus { outline: none; }

/* After: a clear, high-contrast indicator */
:focus-visible {
  outline: 3px solid #0b5cff;
  outline-offset: 2px;
}

WCAG 2.2 fügt 2.4.11 hinzu: Wenn ein Element den Fokus erhält, darf es nicht vollständig hinter fixierten Kopfzeilen, Cookie-Bannern oder Chat-Widgets verborgen sein. Öffnen Sie ein Modal, tabben Sie hindurch und stellen Sie sicher, dass das fokussierte Element nie verdeckt wird.

Nichtssagende Links und Schaltflächen

Wen es betrifft: Screenreader-Nutzer, die eine Liste aller Links aufrufen, um eine Seite zu überfliegen, und Menschen mit kognitiven Behinderungen.

WCAG-Kriterien: 2.4.4 Linkzweck (im Kontext), Level A; 2.5.3 Beschriftung im Namen, Level A.

Screenreader-Nutzer navigieren oft, indem sie kontextlos zwischen Links springen. Eine Seite voller „hier klicken”, „mehr lesen” und „mehr erfahren”-Links wird bedeutungslos, wenn sie als Liste vorgelesen wird. Linktext sollte sein Ziel für sich allein beschreiben. Dasselbe gilt für reine Symbolschaltflächen, die einen zugänglichen Namen benötigen.

<!-- Before: ambiguous out of context -->
<a href="/resources/wcag">Read more</a>

<!-- After: self-describing -->
<a href="/resources/wcag">Read our WCAG 2.2 compliance guide</a>

<!-- Icon button with an accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true">…</svg>
</button>

Wen es betrifft: Screenreader-Nutzer, Tastaturnutzer und Menschen mit kognitiven Behinderungen.

WCAG-Kriterium: 2.4.1 Blöcke umgehen (Level A).

Ein Mega-Menü mit Dutzenden von Links zwingt Screenreader- und Tastaturnutzer, auf jeder Seite die gesamte Liste durchzuarbeiten, bevor sie den Inhalt erreichen. Ein „Zum Hauptinhalt springen”-Link als erstes fokussierbares Element lässt sie direkt an wiederholten Blöcken vorbeispringen. Gruppieren Sie zusammengehörige Elemente, halten Sie Menüs schlank und stellen Sie sicher, dass der Sprunglink beim Fokussieren sichtbar wird.

<!-- After: first focusable element on the page -->
<a class="skip-link" href="#main">Skip to main content</a>
…
<main id="main">…</main>

Verständlich: Inhalte, die verwirren

Unbeschriftete oder falsch zugeordnete Formularfelder

Wen es betrifft: Screenreader-Nutzer, Menschen mit kognitiven Behinderungen und Nutzer von Sprachsteuerung, die Felder mit Namen ansprechen.

WCAG-Kriterien: 1.3.1 Info und Beziehungen, 3.3.2 Beschriftungen oder Anweisungen und 4.1.2 Name, Rolle, Wert (alle Level A).

Eingaben ohne ein programmatisch zugeordnetes <label> werden als „Textfeld, leer” angesagt — der Nutzer hat keine Ahnung, was er eingeben soll. Platzhaltertext ist kein Ersatz: Er verschwindet bei der Eingabe und erfüllt meist nicht die Kontrastanforderungen. Pflichtfelder, Formatierungsregeln und Validierungsfehler müssen ebenfalls in Textform vermittelt werden, nicht allein durch Farbe oder Position.

<!-- Before: placeholder masquerading as a label -->
<input type="email" placeholder="Email">

<!-- After: explicit, associated label + described error -->
<label for="email">Email address</label>
<input type="email" id="email"
       aria-describedby="email-err" aria-invalid="true">
<p id="email-err">Enter a valid email, e.g. name@example.com</p>

Verknüpfen Sie Fehlermeldungen mit ihrem Feld über aria-describedby, kennzeichnen Sie ungültige Felder mit aria-invalid und stellen Sie sicher, dass beim Absenden eines unvollständigen Formulars der Fokus zum ersten Fehler springt.

Fehlende Seitensprache

Wen es betrifft: Screenreader-Nutzer — die falsche Sprache führt dazu, dass der Synthesizer alles falsch ausspricht.

WCAG-Kriterien: 3.1.1 Sprache der Seite (Level A) und 3.1.2 Sprache von Teilen (Level AA).

Ein einziges fehlendes Attribut zerstört die Aussprache für eine ganze Seite. Deklarieren Sie die primäre Sprache am Wurzelelement und kennzeichnen Sie eingebettete Passagen in einer anderen Sprache mit ihrem eigenen lang.

<!-- Before -->
<html>

<!-- After -->
<html lang="en">
  …
  <blockquote lang="fr">Le client a raison.</blockquote>

Falsche Überschriftenhierarchie und fehlende Landmarken

Wen es betrifft: Screenreader-Nutzer, die per Überschriften und Regionen navigieren, und alle, die sich auf die Dokumentstruktur verlassen.

WCAG-Kriterium: 1.3.1 Info und Beziehungen (Level A).

Überschriften sind die Gliederung der Seite. Screenreader-Nutzer springen von Überschrift zu Überschrift, um Inhalte schnell zu finden; wenn Ebenen übersprungen, rein für die Schriftgröße verwendet werden oder fehlen, bricht diese Navigation zusammen. Jede Seite sollte ein <h1> und eine logische, ununterbrochene Folge von <h2>, <h3> usw. haben. Ebenso wichtig sind Landmarkenregionen — <header>, <nav>, <main>, <footer> —, die es Nutzern ermöglichen, zwischen Hauptbereichen zu springen. Eine vollständig aus <div>-Elementen aufgebaute Seite bietet keine solche Karte.

<!-- After: semantic landmarks + ordered headings -->
<header>…</header>
<nav aria-label="Primary">…</nav>
<main>
  <h1>Common accessibility issues</h1>
  <h2>Perceivable</h2>
    <h3>Missing alt text</h3>
</main>
<footer>…</footer>

Robust: Code, den assistive Technologie nicht interpretieren kann

Unzugängliche benutzerdefinierte Widgets und falsch eingesetztes ARIA

Wen es betrifft: vor allem Screenreader-Nutzer und jede assistive Technologie, die auf einen korrekten Accessibility-Baum angewiesen ist.

WCAG-Kriterium: 4.1.2 Name, Rolle, Wert (Level A).

Benutzerdefinierte Dropdowns, Tabs, Akkordeons, Comboboxen, Modale und Tooltips, die aus <div> und <span> gebaut sind, haben keine inhärente Rolle, keinen Zustand und kein Tastaturverhalten. Entwickler greifen zu ARIA, um dies zu flicken, aber ARIA beschreibt nur — es fügt kein Verhalten hinzu, und falsches ARIA ist schlimmer als keines. Die erste Regel von ARIA lautet, ein natives HTML-Element zu bevorzugen, wann immer eines existiert. Wenn Sie ein benutzerdefiniertes Widget bauen müssen, implementieren Sie die vollständige Tastaturinteraktion, die die ARIA-Authoring-Patterns vorschreiben, und halten Sie aria-expanded, aria-selected und ähnliche Zustände mit der Realität synchron.

<!-- Before: a div pretending to be a control, no role or state -->
<div class="dropdown" onclick="toggle()">Choose plan ▾</div>

<!-- After: correct role, name, and state -->
<button aria-expanded="false" aria-controls="plan-list">
  Choose plan
</button>
<ul id="plan-list" role="listbox" hidden>…</ul>

Genau das sind die Probleme, die automatisierte Scanner am häufigsten übersehen. Ein Scanner sieht ein aria-expanded-Attribut und lässt es durchgehen; nur ein Mensch (oder ein Tester, der einen Screenreader verwendet) kann bestätigen, dass der Wert tatsächlich umschaltet, wenn das Menü geöffnet wird. Sehen Sie sich unseren Leitfaden zum Screenreader-Test an, um zu erfahren, wie Sie das Widget-Verhalten von Anfang bis Ende überprüfen.

Ein Hinweis zu Overlay-Widgets

Es ist verlockend, ein einzeiliges „Barrierefreiheits-Widget” oder Overlay zu installieren, das sofortige Compliance verspricht. Diese Tools beheben die oben genannten Probleme nicht — der Alternativtext fehlt weiterhin im Quellcode, der Kontrast scheitert weiterhin, das benutzerdefinierte Widget funktioniert weiterhin nicht. Overlays können den Code, der die Barrieren verursacht, nicht beheben, sie stören häufig die eigene assistive Technologie der Nutzer und sie sind in einer wachsenden Zahl von Barrierefreiheitsklagen aufgetaucht. Echte digitale Barrierefreiheit entsteht durch das Beheben des zugrunde liegenden HTML, CSS und Verhaltens, nicht durch das Kaschieren.

Verhindern Sie, dass diese Probleme wiederkehren

Eine Liste von Fehlern einmal zu beheben ist notwendig, aber nicht ausreichend; dieselben Probleme tauchen mit der nächsten Version wieder auf, es sei denn, Sie ändern die Art und Weise, wie Sie ausliefern. Die dauerhafte Lösung besteht darin, Barrierefreiheit in den Arbeitsablauf einzubauen:

Fangen Sie die automatisierbaren 30–40 % früh ab, indem Sie Scans in Ihre Pipeline einbinden. Die CI/CD-Integration für Barrierefreiheit lässt den Build fehlschlagen, wenn eine Regression eingeführt wird, bevor sie die Produktion erreicht.
Decken Sie den Rest mit Menschen ab. Planen Sie manuelle Barrierefreiheits-Audits und Audits durch Menschen mit Behinderungen ein, die Barrieren aufdecken, die kein Tool erkennen kann.
Geben Sie Teams die richtigen Werkzeuge. Das QualiBooth-Toolkit für Barrierefreiheit und Agora helfen Designern und Entwicklern, während der Arbeit zu testen.
Machen Sie es zu einem Prozess, nicht zu einem Projekt. Laufende Beratung zur Barrierefreiheit und Verbesserung des Barrierefreiheitsprozesses verankern die Gewohnheiten, sodass die Qualität über die Zeit erhalten bleibt.

Für eine schrittweise Roadmap zur Behebung beginnen Sie mit unserem Leitfaden, wie Sie Ihre Website WCAG-konform machen.

Wo Sie heute beginnen sollten

Da weltweit über 1,3 Milliarden Menschen mit einer Form von Behinderung leben, ist das wirtschaftliche Argument für Barrierefreiheit eindeutig — und seit Juni 2025 gilt das auch für das rechtliche Argument im Rahmen des European Accessibility Act. Die Probleme in diesem Katalog sind diejenigen, die bei jeder Beschwerde oder jedem Audit zuerst untersucht werden.

Der schnellste Weg, um zu sehen, wo Sie stehen, ist ein kostenloser URL-Scan — keine Einrichtung, keine Verpflichtung. Wenn Sie bereit sind, über das hinauszugehen, was Automatisierung erreichen kann, fordern Sie eine Demo an, und wir zeigen Ihnen, wie ein kombiniertes Programm aus Automatisierung und manueller Prüfung die verbleibende Lücke schließt.