European Accessibility Act: Was der EAA für Ihre Website bedeutet

TL;DR

Der European Accessibility Act (EAA) gilt seit dem 28. Juni 2025. Er verpflichtet Unternehmen, die digitale Produkte oder Dienstleistungen in der EU anbieten, zur Einhaltung der WCAG 2.1 AA. Frankreich hat im November 2025 die ersten Klagen eingereicht. Deutschland setzt auf private Abmahnungen. Bußgelder reichen je nach Mitgliedstaat von 30.000 EUR bis über 1 Million EUR. 96% aller Websites erfüllen die Anforderungen aktuell nicht.

Die Zahlen

Die WebAIM Million-Studie 2025 hat eine Million Startseiten automatisiert geprüft. Das Ergebnis: durchschnittlich 56,8 WCAG-Verstöße pro Seite.^[1] Die häufigsten Fehler (niedriger Kontrast, fehlende Alt-Texte, fehlende Formular-Labels) lassen sich in den meisten Fällen innerhalb weniger Stunden beheben.

Was der European Accessibility Act tatsächlich verlangt

Der EAA (Richtlinie (EU) 2019/882) harmonisiert die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen im EU-Binnenmarkt. Die Richtlinie definiert funktionale Anforderungen. Die technische Umsetzung für digitale Inhalte verweist auf die europäische Norm EN 301 549, die wiederum die WCAG 2.1 auf Stufe AA als Mindeststandard referenziert.^[2]

Geltungsbereich: Produkte

• Computer und Betriebssysteme
• Smartphones und Tablets
• TV-Geräte mit Internetzugang
• E-Book-Reader
• Selbstbedienungsterminals: Geldautomaten, Fahrkartenautomaten, Check-in-Terminals
• Router und Modems

Geltungsbereich: Dienstleistungen

• E-Commerce-Websites und mobile Apps
• Bankdienstleistungen und Online-Banking
• Elektronische Kommunikationsdienste (VoIP, Messenger)
• Streaming-Dienste und audiovisuelle Mediendienste
• E-Books und dedizierte Software
• Personenbeförderungsdienste (Flug, Bahn, Bus, Fähre): Websites, Apps, Ticketautomaten
• Notrufnummern und deren digitale Schnittstellen

Die harmonisierte Norm EN 301 549 v3.2.1 übernimmt alle WCAG 2.1 Level A und AA Erfolgskriterien und ergänzt sie um Anforderungen für Software, Hardware und Dokumentation. Wer WCAG 2.1 AA vollständig erfüllt, deckt den Webanteil der EN 301 549 ab.^[3]

Wer muss sich daran halten

Der EAA erfasst alle Unternehmen, die Produkte oder Dienstleistungen aus dem Geltungsbereich auf dem EU-Markt anbieten. Der Sitz des Unternehmens spielt keine Rolle. Ein US-amerikanischer SaaS-Anbieter mit EU-Kunden fällt genauso darunter wie ein deutscher Onlineshop.

• E-Commerce: Jeder Onlineshop, der an EU-Verbraucher verkauft
• SaaS: Webbasierte Software mit EU-Nutzern (CRM, Projektmanagement, Buchhaltung)
• Banking: Online-Banking, Mobile-Banking-Apps, Geldautomaten
• Streaming: Video- und Audioplattformen mit EU-Publikum
• Transport: Buchungsportale für Flüge, Bahn, Fernbusse
• Telekommunikation: Messenger, VoIP-Dienste, E-Mail-Provider

Die Durchsetzung in der Praxis

Die Richtlinie überlässt die Durchsetzung den Mitgliedstaaten. Jedes Land hat eigene Marktüberwachungsbehörden benannt und eigene Sanktionsrahmen definiert. Stand Mai 2026 zeigt sich ein klares Bild: Die Durchsetzung hat begonnen.

Frankreich: Erste Klagen im November 2025

Die französische Vereinigung Accès Libre hat im November 2025 Klagen gegen Auchan, Carrefour, E.Leclerc und Picard eingereicht. Grundlage: Artikel 47 des französischen Behindertengleichstellungsgesetzes in Verbindung mit der EAA-Umsetzung. Die Klagen zielen auf die mangelnde Barrierefreiheit der E-Commerce-Plattformen dieser Unternehmen.^[4]

Norwegen: 50.000 NOK täglich

Die norwegische Behörde für universelles Design (UU-tilsynet) verhängt tägliche Zwangsgelder von bis zu 50.000 NOK (ca. 4.300 EUR) bis zur Herstellung der Konformität. Norwegen wendet den EAA als EWR-Mitglied an und hat eine der aktivsten Aufsichtsbehörden in Europa.^[5]

Deutschland: Private Abmahnungen

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den EAA in deutsches Recht um. Die Marktüberwachung liegt bei den Landesbehörden. Parallel dazu ermöglicht das deutsche Wettbewerbsrecht (UWG) privaten Verbänden, Abmahnungen wegen fehlender Barrierefreiheit auszusprechen. Erste Abmahnwellen sind bereits dokumentiert.^[6]

Schweden und Niederlande

Schweden hat die Post- och telestyrelsen (PTS) als Aufsichtsbehörde benannt und ein formelles Überwachungsprogramm gestartet. Die Niederlande setzen auf die Autoriteit Consument & Markt (ACM), die bereits branchenweite Prüfungen angekündigt hat.

Bußgelder nach Land

Die Sanktionsrahmen variieren erheblich zwischen den Mitgliedstaaten. Die folgende Übersicht zeigt die wichtigsten Märkte.^[7]

Deutschland

Bis zu 100.000 EUR pro Verstoß gemäß BFSG. Die Marktüberwachungsbehörden können zusätzlich Vertriebsverbote und Rückrufe anordnen. Dazu kommen mögliche Abmahnkosten durch Wettbewerbsverbände.

Frankreich

Bis zu 50.000 EUR pro Verstoß. Bei wiederholten Verstößen innerhalb von drei Jahren verdoppelt sich der Rahmen. Die DGCCRF (Direction générale de la concurrence, de la consommation et de la répression des fraudes) ist zuständig.

Spanien

Spanien staffelt die Bußgelder in drei Stufen: Leichte Verstöße bis 30.000 EUR, schwere Verstöße von 30.001 bis 90.000 EUR, sehr schwere Verstöße von 90.001 bis 1.000.000 EUR. Die höchste Stufe trifft bei systematischer Diskriminierung oder wiederholten Verstößen zu.

Irland

Bis zu 60.000 EUR Geldstrafe. Irland sieht zusätzlich bis zu 18 Monate Haft für verantwortliche Personen bei vorsätzlichen Verstößen vor. Das macht Irland zum Mitgliedstaat mit den härtesten persönlichen Konsequenzen.

Italien

Italiens Agenzia per l'Italia Digitale (AgID) kann Bußgelder von 5.000 bis 40.000 EUR pro Verstoß verhängen. Bei fehlender Barrierefreiheitserklärung: zusätzlich 20.000 EUR. Die AgID hat bereits 2024 verstärkt Prüfungen durchgeführt.

Niederlande

Die ACM kann Bußgelder von bis zu 900.000 EUR oder 1% des Jahresumsatzes verhängen (je nachdem, welcher Betrag höher ist). Die Niederlande gehören damit zu den Ländern mit dem höchsten Bußgeldrahmen.

Auch in den USA: Barrierefreiheit wird Pflicht

Der Trend beschränkt sich nicht auf Europa. Die USA verschärfen parallel die Anforderungen an digitale Barrierefreiheit.

ADA Title II: Frist 24. April 2026

Das US-Justizministerium hat im April 2024 eine finale Regel unter Title II des Americans with Disabilities Act (ADA) veröffentlicht. Sie verpflichtet alle staatlichen und kommunalen Behörden, ihre Webinhalte und mobilen Apps bis zum 24. April 2026 (große Behörden) bzw. 24. April 2027 (kleine Behörden) WCAG 2.1 AA-konform zu gestalten.^[8]

Section 508 und HHS-Regel

Section 508 des Rehabilitation Act verlangt seit 2018 WCAG 2.0 AA für alle Bundesbehörden und deren Auftragnehmer. Das Department of Health and Human Services (HHS) hat 2024 eine eigene Regel vorgeschlagen, die Barrierefreiheitsanforderungen auf alle Empfänger von HHS-Fördergeldern ausdehnt: Krankenhäuser, Versicherungen, Arztpraxen.

Strafen in den USA

ADA-Verstöße ziehen Zivilstrafen nach sich: 55.000 USD für das erste Vergehen, 150.000 USD für jedes weitere Vergehen. Hinzu kommen Anwaltshonorare und Schadensersatz. Die Zahl der ADA-bezogenen Klagen im digitalen Bereich lag 2025 bei über 4.600.^[9]

Die WCAG 2.1 AA Checkliste

WCAG 2.1 organisiert die Erfolgskriterien nach vier Prinzipien: Wahrnehmbar (Perceivable), Bedienbar (Operable), Verständlich (Understandable) und Robust. Die Level-AA-Konformität umfasst alle Level-A- und Level-AA-Kriterien.^[10]

Wahrnehmbar (Perceivable)

• Alt-Text für Bilder (1.1.1): Jedes informative Bild braucht einen beschreibenden Alternativtext. Dekorative Bilder erhalten alt="".
• Untertitel für Videos (1.2.2): Alle vorproduzierten Videos mit Audio benötigen synchronisierte Untertitel.
• Audiodeskription (1.2.5): Videos mit visuellen Informationen, die nicht im Audio enthalten sind, brauchen eine Audiodeskription.
• Kontrastverhältnis 4,5:1 (1.4.3): Normaler Text benötigt ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund. Großer Text (ab 18pt oder 14pt fett): mindestens 3:1.
• Textvergrößerung auf 200% (1.4.4): Der gesamte Text muss ohne Informationsverlust auf 200% vergrößerbar sein.
• Content Reflow bei 320px (1.4.10): Bei einer Viewport-Breite von 320 CSS-Pixeln darf kein horizontales Scrollen erforderlich sein (mit Ausnahmen für Datentabellen und Toolbars).
• Kein reiner Farbbezug (1.4.1): Farbe darf nicht das einzige Mittel sein, um Information zu vermitteln.
• Textabstand anpassbar (1.4.12): Nutzer müssen Zeilenhöhe, Absatzabstand, Buchstaben- und Wortabstand anpassen können, ohne dass Inhalte verloren gehen.

Bedienbar (Operable)

• Tastaturnavigation (2.1.1): Alle Funktionen müssen per Tastatur erreichbar sein.
• Keine Tastaturfallen (2.1.2): Der Tastaturfokus darf in keinem Element gefangen bleiben.
• Skip-Links (2.4.1): Ein Mechanismus zum Überspringen wiederkehrender Navigationsblöcke muss vorhanden sein.
• Sichtbarer Fokus (2.4.7): Der Tastaturfokus muss jederzeit visuell erkennbar sein.
• Ausreichend Zeit (2.2.1): Zeitlimits müssen abschaltbar, verlängerbar oder mindestens zehnmal verlängerbar sein.
• Keine Bewegungsfallen (2.3.1): Inhalte dürfen nicht mehr als dreimal pro Sekunde blitzen.
• Seitenüberschriften (2.4.2): Jede Seite braucht einen beschreibenden Titel.
• Link-Zweck erkennbar (2.4.4): Der Zweck eines Links muss aus dem Linktext oder seinem Kontext hervorgehen.

Verständlich (Understandable)

• Sprachattribut (3.1.1): Die Hauptsprache der Seite muss im lang-Attribut des <html>-Elements definiert sein.
• Sprache von Abschnitten (3.1.2): Fremdsprachige Passagen brauchen ein eigenes lang-Attribut.
• Konsistente Navigation (3.2.3): Navigationsmenüs müssen auf allen Seiten in derselben Reihenfolge erscheinen.
• Konsistente Benennung (3.2.4): Elemente mit gleicher Funktion müssen konsistent benannt sein.
• Fehleridentifikation (3.3.1): Eingabefehler müssen automatisch erkannt und dem Nutzer in Textform beschrieben werden.
• Labels für Eingabefelder (3.3.2): Jedes Eingabefeld braucht ein zugeordnetes Label oder eine Anweisung.
• Fehlervorschläge (3.3.3): Wenn ein Fehler erkannt wird und Korrekturvorschläge bekannt sind, müssen diese angeboten werden.
• Fehlervermeidung bei rechtlichen Daten (3.3.4): Transaktionen mit rechtlichen oder finanziellen Folgen müssen umkehrbar, prüfbar oder bestätigbar sein.

Robust

• Valides HTML (4.1.1): Elemente haben vollständige Start- und End-Tags, sind korrekt verschachtelt und enthalten keine doppelten Attribute. (Hinweis: Dieses Kriterium wurde in WCAG 2.2 als "always satisfied" eingestuft, bleibt in 2.1 AA aber relevant.)
• Name, Rolle, Wert (4.1.2): Alle UI-Komponenten müssen einen programmatisch bestimmbaren Namen und eine Rolle haben. Zustandsänderungen müssen an Assistive Technology kommuniziert werden.
• Statusmeldungen (4.1.3): Statusmeldungen (Erfolg, Fehler, Warnung) müssen per ARIA-Live-Regions an Screenreader kommuniziert werden, ohne den Fokus zu verschieben.

Die 10 häufigsten Barrierefreiheits-Fehler

Die WebAIM Million-Analyse 2025 hat die häufigsten WCAG-Verstöße auf einer Million Startseiten identifiziert. Die folgende Liste basiert auf dieser Datengrundlage und ergänzt sie um Erkenntnisse aus unseren eigenen Audits.^[1]

1. Niedriger Farbkontrast

Auf 81% aller geprüften Seiten gefunden. Häufigste Ursache: hellgrauer Text auf weißem Hintergrund. Mindestanforderung: 4,5:1 für normalen Text, 3:1 für großen Text. Tools wie der WebAIM Contrast Checker prüfen Farbkombinationen in Sekunden.

2. Fehlender Alt-Text

Auf 54% aller Seiten. Bilder ohne alt-Attribut oder mit nichtssagendem Alt-Text (alt="Bild", alt="IMG_2847.jpg"). Screenreader lesen in solchen Fällen den Dateinamen vor.

3. Fehlende Formular-Labels

Auf 48% aller Seiten. Eingabefelder ohne zugeordnetes <label>-Element oder aria-label. Placeholder-Text ersetzt kein Label: Er verschwindet bei der Eingabe und wird von manchen Screenreadern ignoriert.

4. Fehlerhafte ARIA-Attribute

Auf 34% aller Seiten. Typische Fehler: aria-labelledby verweist auf nicht existierende IDs, role="button" auf einem <div> ohne Tastaturhandler, aria-hidden="true" auf fokussierbaren Elementen. Die erste Regel von ARIA lautet: Wenn ein natives HTML-Element die Aufgabe erfüllt, verwende kein ARIA.

5. Fehlende Skip-Navigation

Auf 32% aller Seiten. Tastaturnutzer müssen auf jeder Seite durch die gesamte Navigation tabben, bevor sie den Hauptinhalt erreichen. Ein einfacher Skip-Link löst das Problem.

6. Fehlendes Sprachattribut

Auf 17% aller Seiten. Ohne lang-Attribut auf dem <html>-Element kann der Screenreader die falsche Sprachausgabe verwenden. Ein deutschsprachiger Text wird dann möglicherweise mit englischer Phonetik vorgelesen.

7. Automatisch abspielende Medien

Videos oder Audio, die beim Seitenaufruf automatisch starten, stören Screenreader-Nutzer erheblich. Die Sprachausgabe wird vom Medienton überlagert. Medien dürfen automatisch starten, wenn sie kürzer als drei Sekunden sind oder ein Mechanismus zum Stoppen/Stummschalten sofort verfügbar ist.

8. Tastaturfallen

Modale Dialoge, Dropdown-Menüs und eingebettete Widgets (Kartenwidgets, CAPTCHA-Frames) fangen den Tastaturfokus. Der Nutzer kann das Element nicht per Tastatur verlassen. Jedes interaktive Element muss einen dokumentierten Tastaturmechanismus zum Verlassen bieten.

9. Fehlende Fokus-Indikatoren

CSS-Deklarationen wie outline: none oder :focus { outline: 0 } entfernen den sichtbaren Fokusring. Tastaturnutzer sehen dann nicht, welches Element aktuell fokussiert ist. Der Fokusindikator muss jederzeit sichtbar sein.

10. Nicht barrierefreie PDFs

PDFs ohne Tags, ohne Lesereihenfolge und ohne Alternativtexte für eingebettete Grafiken. Gescannte Dokumente ohne OCR-Layer sind für Screenreader komplett unsichtbar. Der EAA erfasst PDFs als Teil der Dienstleistung: Ein Onlineshop, der AGB oder Produktdatenblätter als nicht barrierefreie PDFs anbietet, verstößt gegen die Anforderungen.

Website-Audit durchführen

Ein vollständiger Barrierefreiheits-Audit kombiniert automatisierte Tests, manuelle Prüfungen und Nutzertests. Automatisierte Tools allein finden laut GDS-Studie nur 30 bis 40% aller WCAG-Verstöße.^[11]

Automatisierte Tools

• axe DevTools (Deque): Browser-Extension für Chrome und Firefox. Prüft die aktuelle Seite gegen WCAG 2.1 AA. Kostenlose Basisversion verfügbar.
• Lighthouse (Google): In Chrome DevTools integriert. Der Accessibility-Score basiert auf axe-core. Gut für schnelle Übersichtstests.
• WAVE (WebAIM): Browser-Extension, die Fehler direkt im Seitenkontext visualisiert. Besonders nützlich für die Kommunikation mit Designern.
• Pa11y: Open-Source-CLI-Tool für CI/CD-Integration. Kann WCAG-Prüfungen in die Build-Pipeline einbinden.

Manuelle Tests

• Tastaturtest: Gesamte Website nur mit Tastatur bedienen. Tab, Shift+Tab, Enter, Escape, Pfeiltasten. Prüfen: Erreiche ich alle interaktiven Elemente? Ist der Fokus immer sichtbar? Kann ich Modale schließen?
• Screenreader-Test: VoiceOver (macOS/iOS), NVDA (Windows, kostenlos) oder JAWS (Windows). Mindestens die Startseite, eine Produktseite und den Checkout-Prozess testen.
• Zoom-Test: Browser auf 200% zoomen. Prüfen: Werden Inhalte abgeschnitten? Überlagern sich Elemente? Funktioniert die Navigation noch?
• Kontrast-Prüfung: Alle Texte, Icons und interaktiven Elemente gegen ihre Hintergründe prüfen.

Nutzertests

Tests mit Menschen, die Assistive Technology im Alltag nutzen, decken Probleme auf, die kein automatisiertes Tool und kein manueller Test findet. Organisationen wie die Deutsche Blinden- und Sehbehindertenverband (DBSV) oder Aktion Mensch vermitteln Tester.

Quick Wins für diese Woche

Die folgenden Maßnahmen lassen sich innerhalb weniger Stunden umsetzen und beheben die häufigsten Verstöße.

1. Sprachattribut setzen

<!-- Vorher -->
<html>

<!-- Nachher -->
<html lang="de">

Eine Zeile. Behebt WCAG 3.1.1 auf der gesamten Website.

2. Skip-Link einfügen

<body>
  <a href="#main-content" class="skip-link">
    Zum Hauptinhalt springen
  </a>
  <nav><!-- Navigation --></nav>
  <main id="main-content">
    <!-- Seiteninhalt -->
  </main>
</body>

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  padding: 8px 16px;
  background: #121512;
  color: #ffffff;
  z-index: 100;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
}

3. Alt-Texte ergänzen

<!-- Informatives Bild: beschreibenden Alt-Text -->
<img src="/produkt.jpg" alt="Schwarzer Lederrucksack mit zwei Außentaschen, Frontansicht">

<!-- Dekoratives Bild: leerer Alt-Text -->
<img src="/divider.svg" alt="">

4. Fokus-Styles reparieren

/* Niemals den Fokus komplett entfernen */
/* :focus { outline: none; }  <-- NICHT machen */

/* Stattdessen: sichtbaren, ästhetischen Fokus definieren */
:focus-visible {
  outline: 2px solid #121512;
  outline-offset: 2px;
}

/* Mausklicks ohne sichtbaren Fokusring */
:focus:not(:focus-visible) {
  outline: none;
}

5. Formular-Labels zuordnen

<!-- Vorher: Placeholder als Pseudo-Label -->
<input type="email" placeholder="E-Mail-Adresse">

<!-- Nachher: Echtes Label -->
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email">

6. Kontrast korrigieren

/* Vorher: Kontrast 2,5:1 (WCAG-Verstoß) */
.muted-text {
  color: #969696; /* auf #ffffff Hintergrund */
}

/* Nachher: Kontrast 4,6:1 (WCAG AA konform) */
.muted-text {
  color: #767676; /* auf #ffffff Hintergrund */
}

7. Überschriften-Hierarchie prüfen

<!-- Falsch: Ebene übersprungen -->
<h1>Produkte</h1>
<h3>Kategorie A</h3>  <!-- h2 fehlt -->

<!-- Richtig: Lückenlose Hierarchie -->
<h1>Produkte</h1>
<h2>Kategorie A</h2>
<h3>Unterkategorie</h3>

8. ARIA-Landmarks setzen

<header role="banner">
  <nav role="navigation" aria-label="Hauptnavigation">
    <!-- Links -->
  </nav>
</header>

<main role="main">
  <!-- Seiteninhalt -->
</main>

<footer role="contentinfo">
  <!-- Footer -->
</footer>

Die semantischen HTML5-Elemente (<header>, <nav>, <main>, <footer>) haben implizite ARIA-Rollen. Die expliziten role-Attribute sind für ältere Screenreader hilfreich.

9. Bilder als Links beschriften

<!-- Vorher: Screenreader liest "Link, Grafik" -->
<a href="/">
  <img src="/logo.svg">
</a>

<!-- Nachher: Screenreader liest "Link, TechTurm Startseite" -->
<a href="/" aria-label="TechTurm Startseite">
  <img src="/logo.svg" alt="">
</a>

10. Statusmeldungen mit ARIA Live Regions

<!-- Erfolgs-/Fehlermeldungen für Screenreader ankündigen -->
<div role="status" aria-live="polite">
  <!-- Wird dynamisch befüllt -->
</div>

<div role="alert" aria-live="assertive">
  <!-- Für kritische Fehlermeldungen -->
</div>

Die Barrierefreiheitserklärung

Der EAA verlangt, dass Anbieter eine Barrierefreiheitserklärung (Accessibility Statement) veröffentlichen. Diese Erklärung muss auf der Website leicht auffindbar sein (typischerweise im Footer verlinkt) und regelmäßig aktualisiert werden.

Pflichtinhalte der Erklärung

1. Grad der Konformität mit EN 301 549 bzw. WCAG 2.1 AA (vollständig konform, teilweise konform, nicht konform)
2. Auflistung nicht barrierefreier Inhalte mit Begründung
3. Beschreibung der getroffenen Maßnahmen und des Zeitplans zur Behebung
4. Kontaktmöglichkeit für Nutzer, die auf Barrieren stoßen (Name, E-Mail, Telefon)
5. Datum der letzten Bewertung und Methode der Bewertung (Selbstbewertung, externes Audit)
6. Verweis auf das Durchsetzungsverfahren der zuständigen Behörde

Template-Struktur

# Barrierefreiheitserklärung

[Name des Unternehmens] ist bestrebt, seine Website in Einklang mit
der Richtlinie (EU) 2019/882 (European Accessibility Act) sowie dem
Barrierefreiheitsstärkungsgesetz (BFSG) barrierefrei zugänglich zu machen.

## Stand der Konformität
Diese Website ist [vollständig / teilweise / nicht] konform mit
WCAG 2.1 Level AA.

## Nicht barrierefreie Inhalte
- [Beschreibung der Barriere]: [Grund]. Geplante Behebung: [Datum]

## Kontakt
Bei Problemen mit der Barrierefreiheit dieser Website:
E-Mail: barrierefreiheit@example.de
Telefon: +49 XXX XXXXXXXX

## Durchsetzungsverfahren
Sollten Sie trotz Kontaktaufnahme keine zufriedenstellende Antwort
erhalten, können Sie sich an [zuständige Landesbehörde] wenden.

## Erstellung dieser Erklärung
Diese Erklärung wurde am [Datum] erstellt.
Grundlage: [Selbstbewertung / externes Audit durch Firma X].
Letzte Überprüfung: [Datum].

Quellen