Blog

Best Practices

Top 10 EAA-Verstöße auf europäischen Websites — und wie Sie sie an einem Nachmittag beheben

Zehn WCAG 2.1 AA-Fehler, die auf den meisten EU-Websites auftreten, mit Copy-Paste-Fixes. Beheben Sie diese und Sie decken den Großteil der automatisch erkennbaren EAA-Befunde ab.

8. Mai 2026

Updated 15 May 2026

14 min read

Ravid, Webply

Also in:

EN

DE

NLFR

Wie wir sie gerankt haben

Die Reihenfolge ist nach Häufigkeit × rechtlichem Risiko, nicht nach reiner Vorkommenshäufigkeit. Ein Verstoß, der überall vorkommt, aber selten zitiert wird (z. B. kleinere Überschriftsprünge), rankt niedriger als etwas weniger Verbreitetes, das regelmäßig in Beschwerden auftaucht (z. B. nicht beschriftete Formularfelder auf einer Checkout-Seite).

Für jeden Verstoß erhalten Sie:

• Das WCAG 2.1 AA-Kriterium, das er verletzt
• Die axe-core-Regel, die ihn erkennt
• Warum er eine Beschwerde auslöst
• Den Fix, mit Code

Los geht's.

1. Fehlende Alt-Texte auf aussagekräftigen Bildern

WCAG: 1.1.1 Non-text Content (Level A) · axe-Regel: image-alt

Dies ist der am häufigsten genannte Befund in WCAG-Audits und der einfachste zu beheben.

Der Fehler, den fast jeder macht: alt bei einem dekorativen Bild weglassen, dann auch bei einem aussagekräftigen Bild weglassen. Screenreader kündigen dann nichts für das aussagekräftige Bild an — der Nutzer weiß nicht, dass es ein Produktfoto, eine Grafik oder ein CAPTCHA gibt.

<!-- ❌ Schlecht: aussagekräftiges Bild ohne alt -->
<img src="/products/red-chair.jpg">

<!-- ✅ Gut: aussagekräftiges Bild, beschreibendes alt -->
<img src="/products/red-chair.jpg" alt="Roter Ledersessel, Mid-Century-Stil, Seitenansicht">

<!-- ✅ Gut: dekoratives Bild, leeres alt ist korrekt -->
<img src="/decorative/swoosh.png" alt="">

Wichtige Nuance: alt="" ist die richtige Antwort für wirklich dekorative Bilder. Es ist nicht die richtige Antwort für "Ich weiß nicht, was ich schreiben soll." Eine fehlende Beschreibung auf einem Produktbild kostet Sie eine Beschwerde; ein leeres alt auf einer Dekoration ist die spezifikationskonforme Wahl.

2. Unzureichender Text-Hintergrund-Kontrast

WCAG: 1.4.3 Contrast (Minimum) (Level AA) · axe-Regel: color-contrast

Sie benötigen ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (≥18pt oder ≥14pt fett). Dies ist der häufigste AA-Fehler auf Landing Pages — hellgrauer Text auf weißem Hintergrund, farbige Marken-Buttons, die den Kontrast nicht erfüllen.

So prüfen Sie schnell: Fügen Sie Ihre Vorder-/Hintergrundfarbe in WebAIMs Kontrastprüfer oder Ihre Browser-DevTools (Inspektieren → Accessibility-Tab in Chrome/Firefox) ein.

/* ❌ Schlecht: 2,6:1 Verhältnis, besteht AA nicht */
.muted { color: #aaaaaa; background: #ffffff; }

/* ✅ Gut: 4,6:1 Verhältnis, besteht AA */
.muted { color: #767676; background: #ffffff; }

/* ✅ Gut für Platzhalter und deaktivierte Zustände */
.disabled { color: #595959; background: #ffffff; } /* 7:1 */

Konträre Anmerkung: Viele Design-Systeme (Material, Apple HIG, Tailwind-Defaults) liefern gray-300, gray-400 als häufige Textfarben auf Weiß. Beide bestehen AA nicht. Prüfen Sie Ihre Design-Tokens einmal, nicht Ihre Seiten.

3. Formularfelder ohne programmatische Labels

WCAG: 1.3.1 Info and Relationships (Level A), 4.1.2 Name, Role, Value (Level A) · axe-Regel: label

Dies ist der Verstoß mit dem höchsten rechtlichen Risiko auf E-Commerce-Sites. Ein Checkout-Formular, in dem Screenreader "E-Mail", "Postleitzahl", "CVV" nicht ankündigen können — genau das ist die Art von Fehler, die französische Durchsetzungsmaßnahmen wie die November-2025-Klagen gegen Carrefour und Auchan ausgelöst hat.

<!-- ❌ Schlecht: visueller Platzhalter, kein Label -->
<input type="email" placeholder="E-Mail-Adresse">

<!-- ❌ Schlecht: Label nicht verknüpft -->
<label>E-Mail</label>
<input type="email">

<!-- ✅ Gut: explizite Label-Verknüpfung -->
<label for="email">E-Mail</label>
<input id="email" type="email">

<!-- ✅ Gut: aria-label wenn visuelles Label unpraktisch (z. B. Icon-only) -->
<input type="search" aria-label="Produkte suchen">

<!-- ✅ Gut: aria-labelledby zeigt auf vorhandenen sichtbaren Text -->
<span id="zip-label">Postleitzahl</span>
<input aria-labelledby="zip-label">

placeholder ist niemals ein Ersatz für ein Label. Es verschwindet, wenn der Nutzer zu tippen beginnt.

4. Fehlender Skip-to-Content-Link

WCAG: 2.4.1 Bypass Blocks (Level A) · axe-Regel: skip-link

Nur-Tastatur- und Screenreader-Nutzer müssen auf jeder Seite durch jeden Navigationslink tabben, bevor sie zum Hauptinhalt gelangen. Ein Skip-Link ermöglicht es ihnen, daran vorbeizuspringen.

<!-- Platzieren Sie dies als allererstes fokussierbares Element in <body> -->
<a href="#main" class="skip-link">Zum Hauptinhalt springen</a>
<!-- ... -->
<main id="main">...</main>

/* Visuell verstecken bis fokussiert — niemals display:none verwenden */
.skip-link {
  position: absolute;
  left: -9999px;
  top: 0;
}
.skip-link:focus {
  left: 0;
  background: #000;
  color: #fff;
  padding: 0.75rem 1rem;
  z-index: 9999;
}

Wenn Sie Next.js / Nuxt / SvelteKit verwenden, ist das eine Komponente, die in Ihr Root-Layout importiert wird. Fünf Minuten, behebt einen der am häufigsten markierten Verstöße.

5. Leere Links und Buttons

WCAG: 2.4.4 Link Purpose (Level A), 4.1.2 Name, Role, Value (Level A) · axe-Regeln: link-name, button-name

Icon-only-Buttons und -Links — das Hamburger-Menü, das Such-Icon, das Schließen-X bei Modals — werden häufig ohne barrierefreien Namen ausgeliefert. Screenreader kündigen "Schaltfläche" an, ohne Hinweis, was sie tut.

<!-- ❌ Schlecht: Icon-Button, kein Name -->
<button><svg>...</svg></button>

<!-- ✅ Gut: aria-label gibt den Namen an -->
<button aria-label="Navigationsmenü öffnen">
  <svg aria-hidden="true">...</svg>
</button>

<!-- ✅ Gut: visuell versteckter Text für Screenreader -->
<button>
  <svg aria-hidden="true">...</svg>
  <span class="sr-only">Navigationsmenü öffnen</span>
</button>

aria-hidden="true" auf dem SVG ist wichtig — ohne es kann der Screenreader sowohl das SVG (oft als "Grafik") als auch das Label ankündigen, was störend ist.

6. Fehlendes Sprachattribut auf <html>

WCAG: 3.1.1 Language of Page (Level A) · axe-Regel: html-has-lang

Ohne lang wissen Screenreader nicht, welche Ausspracheregeln sie verwenden sollen — französischer Inhalt wird mit englischer Phonetik vorgelesen, Deutsch auf Französisch, und das Ergebnis ist unverständlich.

<!-- ❌ Schlecht -->
<html>

<!-- ✅ Gut -->
<html lang="de">

<!-- ✅ Gut für mehrsprachigen Inhalt mit einer Primärsprache -->
<html lang="de">
  <body>
    <p>Der englische Begriff <span lang="en">"deadline"</span> wird häufig verwendet.</p>
  </body>
</html>

Das ist ein Attribut. Es gibt keine Entschuldigung dafür, es wegzulassen.

7. Gebrochene Überschriftshierarchie

WCAG: 1.3.1 Info and Relationships (Level A) · axe-Regel: heading-order

Screenreader-Nutzer navigieren per Überschriften — "nächste Überschrift" ist einer der am häufigsten verwendeten Befehle. Wenn Ihre Seite ein h1 hat und dann direkt zu h4 springt und h2 sowie h3 überspringt, ist die Hierarchie gebrochen und die Navigation schlägt fehl.

<!-- ❌ Schlecht: h1 → h4 → h2 -->
<h1>Seitentitel</h1>
<h4>Unterabschnitt</h4>
<h2>Weiterer Abschnitt</h2>

<!-- ✅ Gut: monotonisch, keine übersprungenen Ebenen -->
<h1>Seitentitel</h1>
<h2>Abschnitt</h2>
<h3>Unterabschnitt</h3>
<h2>Nächster Abschnitt</h2>

Ein häufiger Grund ist die Verwendung von Überschriftsebenen für visuelles Styling. Nicht tun. Verwenden Sie die korrekte Ebene für Struktur, dann gestalten Sie mit CSS.

8. Interaktive Elemente ohne Tastaturzugang

WCAG: 2.1.1 Keyboard (Level A) · axe-Regel: keyboard (manuelle + automatisierte Prüfungen)

Jedes anklickbare Element muss per Tastatur allein erreichbar und bedienbar sein. Der häufigste Fehler: <div onclick=...> statt <button> verwenden.

<!-- ❌ Schlecht: nicht per Tastatur fokussierbar, nicht als Button angekündigt -->
<div class="btn" onclick="doThing()">Klicken</div>

<!-- ✅ Gut: native Semantik gibt Tastatur + Screenreader kostenlos -->
<button type="button" onclick="doThing()">Klicken</button>

<!-- ✅ Gut: wenn Sie absolut ein div verwenden müssen, brauchen Sie all das -->
<div
  role="button"
  tabindex="0"
  onclick="doThing()"
  onkeydown="if(event.key==='Enter'||event.key===' '){doThing()}"
>
  Klicken
</div>

Die dritte Option ist fast immer falsch. Verwenden Sie einen <button>. Das semantische Element gewinnt bei jeder Metrik — Barrierefreiheit, Tastatur, Fokus-Stile, Screenreader-Ankündigung, Browser-Autofill.

9. Modals ohne Fokus-Management

WCAG: 2.4.3 Focus Order (Level A), 2.1.2 No Keyboard Trap (Level A) · teilweise Automation, meist manuell

Ein Modal, das den Fokus nicht begrenzt, ist häufige Ursache für "Ich habe das Modal geöffnet und konnte dann nicht mehr heraus." Wenn ein Modal öffnet, muss der Fokus in das Modal verschoben werden; während es offen ist, sollte Tab innerhalb des Modals zyklisch wechseln; beim Schließen kehrt der Fokus zum Auslöser zurück.

Der richtige Weg 2026 ist das native <dialog>-Element:

<!-- ✅ Gut: nativer dialog mit showModal() handhabt Focus-Trap automatisch -->
<button type="button" onclick="document.getElementById('confirm-dialog').showModal()">
  Konto löschen
</button>

<dialog id="confirm-dialog" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Löschung bestätigen</h2>
  <p>Dies kann nicht rückgängig gemacht werden.</p>
  <form method="dialog">
    <button value="cancel">Abbrechen</button>
    <button value="confirm">Löschen</button>
  </form>
</dialog>

Für React/Vue/Svelte-Komponentenbibliotheken prüfen Sie, ob Ihre Modal-Komponente aria-modal, Focus-Trap und ESC-zum-Schließen unterstützt. Die populären (Radix UI, Headless UI, Mantine Modal, MUI Dialog) tun das alle — aber eigene Modals oder ältere Drittanbieter-Widgets oft nicht.

10. Cookie-Banner, die alles blockieren

WCAG: 2.1.1 Keyboard (Level A), 1.4.13 Content on Hover or Focus (Level AA), 4.1.2 · teilweise Automation

Dies ist der für Nutzer sichtbarste Fehler auf europäischen Websites, weil die DSGVO Cookie-Banner auf jede Website gezwungen hat, und die meisten Banner-Implementierungen Barrierefreiheits-Desaster sind:

• Tab-Reihenfolge hält den Nutzer für immer im Banner gefangen
• Buttons sind unbeschriftet oder mit vagem Text beschriftet ("Alle akzeptieren" ohne Kontext)
• Der Banner überlagert den Hauptinhalt, hat aber keine passende role / aria-modal
• Screenreader-Nutzer können ihn nicht schließen

Der Fix:

<!-- ✅ Gut: dialog-Rolle, barrierefreier Name, Fokus-Management -->
<div role="dialog" aria-modal="true" aria-labelledby="cookie-title">
  <h2 id="cookie-title">Cookie-Einwilligung</h2>
  <p>Wir verwenden Cookies für Analysen. Sie können alle akzeptieren, nicht wesentliche ablehnen oder anpassen.</p>
  <button>Alle akzeptieren</button>
  <button>Nicht wesentliche ablehnen</button>
  <button>Anpassen</button>
</div>

Wenn Sie eine CMP (Consent Management Platform) wie Cookiebot, OneTrust oder Iubenda verwenden — prüfen Sie, ob sie WCAG bestehen. Die meisten großen tun das in ihrer Standardkonfiguration; viele selbst entwickelte Banner nicht. Eines der häufigsten französischen Durchsetzungsprobleme Ende 2025 waren speziell unzugängliche Cookie-Banner.

Was ist mit den anderen 30%?

Die zehn oben sind von automatisierten Tools erkennbar. Rund 30 % der WCAG-Fehler können nicht zuverlässig automatisiert werden:

• Ob alt="Foto des CEO" eine aussagekräftige Beschreibung ist (versus alt="Anna Müller, CEO, lächelt in die Kamera")
• Ob Überschriften ihre Abschnitte logisch beschreiben
• Ob die Lesereihenfolge Sinn ergibt
• Ob Inhalt in einfacher Sprache verständlich ist
• Ob Formulare sich nach Fehlern gracefully erholen

Diese erfordern entweder (1) ein manuelles Audit durch einen Accessibility-Spezialisten oder (2) mindestens einen Testdurchlauf mit einem echten Screenreader (NVDA auf Windows ist kostenlos und der Standard für die meisten blinden Nutzer in Europa).

Für die meisten KMU ist der richtige Ansatz: Automatisierung fängt den Großteil ab, dann ein halber Tag mit einem Screenreader, um die wichtigsten Flows zu überprüfen (Startseite → Produkt → Checkout → Konto).

Über Overlay-Widgets, nochmals, mit Nachdruck

Wenn Ihr Projektmanager oder Chef sagt "Lass uns einfach AccessiBe installieren", ist das das Gespräch:

• Sie beheben das zugrunde liegende HTML nicht. Klagen und Beschwerden basieren auf dem Quellcode.
• Sie brechen häufig Screenreader, die bereits auf dem Gerät des Nutzers konfiguriert sind, weil sie ein konkurrierendes Interaktionsmodell obendrauf legen.
• Sie werden von EU-Regulierern nicht anerkannt. Frankreichs Durchsetzungsmaßnahmen zielten speziell auf Konformität auf Quellebene ab.
• Der dominante Overlay-Anbieter einigte sich 2024 mit der FTC auf irreführende Behauptungen über "WCAG-Konformität durch eine JavaScript-Zeile".

Es gibt keine Overlay-Abkürzung, die einer Beschwerde standhält. Beheben Sie die Quelle.

Für einen verwandten Tiefen-Einblick in die rechtlichen Schichten, siehe unsere WCAG vs EN 301 549 vs EAA Erklärung. Für die länderspezifischen Bußgelder, die diese Beschwerden antreiben, siehe unseren EAA-Bußgeld-Leitfaden.