Eine barrierefreie Website ist eine Website, die Menschen mit Behinderungen wahrnehmen, bedienen und verstehen können, und mit dem European Accessibility Act ist sie für viele Unternehmen, die an Verbraucher in der EU verkaufen, inzwischen eine gesetzliche Pflicht. In der Praxis verweist der Rechtsakt auf die harmonisierte Norm EN 301 549, die ihrerseits auf den Web Content Accessibility Guidelines des W3C auf Stufe AA beruht. Dieser Leitfaden erklärt, wer seit wann betroffen ist, was die Standards verlangen, welche Fehler wir am häufigsten finden und wie man sie behebt, einen nummerierten Audit-Ablauf, die Erklärung zur Barrierefreiheit und wie die Durchsetzung in den Mitgliedstaaten funktioniert.
Zuletzt aktualisiert: 27. Oktober 2026.
Was ist der European Accessibility Act?
Der European Accessibility Act ist die Richtlinie (EU) 2019/882, verabschiedet am 17. April 2019. Sie legt gemeinsame Anforderungen an die Barrierefreiheit für eine Reihe von Produkten und Dienstleistungen im EU-Binnenmarkt fest, damit ein Unternehmen ein einziges Regelwerk erfüllt statt in jedem Land ein anderes.
Weil es eine Richtlinie ist, musste jeder Mitgliedstaat sie bis zum 28. Juni 2022 in nationales Recht umsetzen und diese Regeln ab dem 28. Juni 2025 anwenden (in Deutschland mit dem Barrierefreiheitsstärkungsgesetz, BFSG). Seit dem 28. Juni 2025 gilt der European Accessibility Act für erfasste Produkte, die in Verkehr gebracht werden, und für erfasste Dienstleistungen gegenüber Verbrauchern. Was ein Unternehmen konkret tun muss, steht im jeweiligen nationalen Gesetz, das der Richtlinie eng folgt, aber eigene Aufsichtsbehörden und Sanktionen festlegt.
Daneben steht ein älterer Text, die Richtlinie über den barrierefreien Zugang zu Websites öffentlicher Stellen, die Websites und Apps des öffentlichen Sektors betrifft. Der European Accessibility Act ist derjenige, der private Unternehmen erreicht.
Kurz gesagt: Wenn Sie bestimmte Dienstleistungen an Verbraucher in der EU verkaufen, müssen Ihre Website und Ihre App barrierefrei sein. Der Maßstab ist EN 301 549, die WCAG-Stufe AA verwendet. Sehr kleine Dienstleistungsunternehmen sind ausgenommen. Jedes Land setzt seine eigene Fassung der Regeln durch.
Bei Odduel, einer Agentur für Kreation und Technologie in Barcelona und São Paulo, ist Barrierefreiheit ab dem ersten Wireframe Teil jeder Website, und so wird auch unsere Arbeit in Webdesign und Webentwicklung geplant. Der Rest dieses Leitfadens ist das, was wir Kunden sagen, die wissen wollen, wo sie stehen.
Wer muss den EAA erfüllen?
Der Rechtsakt erfasst benannte Produkte und benannte Dienstleistungen, nicht jede Website. Auf der Seite der Dienstleistungen betreffen diese die meisten Websites und Apps:
- E-Commerce-Dienstleistungen: alle Dienstleistungen, die über eine Website oder eine mobile App im Fernabsatz an Verbraucher verkauft werden. Deshalb fallen die meisten Onlineshops unter das Gesetz.
- Bankdienstleistungen für Verbraucher, einschließlich der Websites und Apps, über die sie angeboten werden.
- E-Books und die Software, mit der sie gelesen werden.
- Elektronische Kommunikationsdienste und Dienste, die Zugang zu audiovisuellen Medien bieten.
- Elemente von Personenbeförderungsdiensten im Luft-, Bus-, Schienen- und Schiffsverkehr: Websites, Apps, elektronische Tickets und Reiseinformationen in Echtzeit.
Auf der Seite der Produkte stehen etwa Computer, Smartphones, E-Book-Reader, Zahlungsterminals, Geldautomaten und Fahrkartenautomaten. Wer diese herstellt oder einführt, für den gilt der Rechtsakt für die Hardware und ihre Software, nicht nur für eine Website.
Ein Unternehmen außerhalb der EU ist nicht außer Reichweite: Entscheidend ist, dass die Leistung Verbrauchern in der EU angeboten wird. Ein Unternehmen, das nur an andere Unternehmen verkauft und keine Leistung für Verbraucher anbietet, fällt in der Regel nicht unter den E-Commerce-Bereich; viele Websites bedienen allerdings beide, und dann ist der Teil für Verbraucher erfasst.
Die Ausnahme für Kleinstunternehmen
Die Richtlinie nimmt Kleinstunternehmen aus, die Dienstleistungen erbringen. Ein Kleinstunternehmen beschäftigt nach der Definition der Richtlinie weniger als zehn Personen und hat einen Jahresumsatz oder eine Jahresbilanzsumme unter einer niedrigen Schwelle, die im Text festgelegt ist. Ein kleines Studio, das Leistungen online verkauft, kann deshalb von der Pflicht ausgenommen sein.
Zwei Punkte werden oft übersehen. Die Ausnahme gilt nur für Dienstleistungen: Ein Kleinstunternehmen, das erfasste Produkte herstellt oder verkauft, muss die Produktanforderungen trotzdem erfüllen, mit weniger Dokumentation. Und heute ausgenommen zu sein macht eine nicht barrierefreie Website nicht zu einer guten Idee, denn ein Unternehmen, das über die Schwelle wächst, fällt unter die Pflicht, und Kunden mit Behinderungen sind so oder so Kunden.
Inhalte und Verträge mit Sonderregeln
Die Richtlinie nimmt manche Inhalte von den Anforderungen aus: vorab aufgezeichnete Audio- und Videoinhalte, die vor dem 28. Juni 2025 veröffentlicht wurden, Office-Dokumente, die vor diesem Datum veröffentlicht wurden, archivierte Inhalte, die seitdem nicht bearbeitet wurden, Online-Karten, wenn die wesentlichen Informationen barrierefrei angeboten werden, und Inhalte Dritter, die das Unternehmen weder finanziert noch kontrolliert. Dienstleistungsverträge, die vor dem 28. Juni 2025 geschlossen wurden, dürfen unverändert bis zu ihrem Ende weiterlaufen, höchstens fünf Jahre lang.
Ein Unternehmen kann auch geltend machen, dass eine Anforderung eine unverhältnismäßige Belastung darstellen oder die Leistung grundlegend verändern würde. Diese Behauptung muss anhand der Kriterien der Richtlinie bewertet und dokumentiert werden, und die Behörden können sie einsehen wollen. Ein allgemeiner Ausstieg ist das nicht.
Welcher Standard gilt?
Die Richtlinie beschreibt Barrierefreiheit funktional: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein. Um daraus Prüfungen zu machen, stützt sich die EU auf harmonisierte Normen, und für Websites und Apps ist das EN 301 549, die europäische Norm für die Barrierefreiheit von Informations- und Kommunikationstechnik. Wer eine harmonisierte Norm erfüllt, deren Fundstelle für den Rechtsakt veröffentlicht ist, für den gilt eine Konformitätsvermutung.
Für Webinhalte übernimmt EN 301 549 die Erfolgskriterien der Web Content Accessibility Guidelines des W3C auf den Stufen A und AA. Die aktuelle Fassung der Norm baut auf WCAG 2.1 auf. Die neuere WCAG 2.2, seit Oktober 2023 eine W3C-Empfehlung, behält die Kriterien von 2.1 (bis auf ein veraltetes Kriterium zum Parsing) und fügt neun weitere hinzu, sechs davon auf den Stufen A und AA.
Unser Rat: Entwickeln und testen Sie nach WCAG 2.2 AA. Eine Website, die sie erfüllt, erfüllt auch die Kriterien von 2.1, die heute nach der Norm geprüft werden, und ist für die nächste Fassung von EN 301 549 bereit, statt einen zweiten Durchgang zu brauchen.
| WCAG 2.1 AA | WCAG 2.2 AA | |
|---|---|---|
| Status | W3C-Empfehlung, 2018 | W3C-Empfehlung, Oktober 2023 |
| Heute von EN 301 549 genutzt | Ja | Noch nicht |
| Fokus sichtbar und nicht verdeckt | Der Fokus muss sichtbar sein | Der Fokus darf zudem nicht ganz von festen Leisten oder Bannern verdeckt sein |
| Kleine Bedienelemente | Keine Mindestgröße auf Stufe AA | Ziele mindestens 24 mal 24 CSS-Pixel oder genug Abstand |
| Ziehbewegungen | Auf Stufe AA nicht abgedeckt | Eine Alternative zum Ziehen mit einem einzigen Zeiger |
| Formulare | Beschriftungen und Hilfe bei Fehlern | Zudem keine erneute Eingabe bereits gemachter Angaben |
| Anmeldung | Nicht abgedeckt | Kein Gedächtnis- oder Rätseltest ohne Alternative |
| Hilfe | Nicht abgedeckt | Hilfeangebote auf jeder Seite an derselben Stelle |
Was bedeutet WCAG 2.2 AA in der Praxis?
WCAG besteht aus prüfbaren Erfolgskriterien, geordnet nach vier Prinzipien. Übersetzt in das, was ein Besucher erlebt, verlangt Stufe AA ungefähr Folgendes:
- Wahrnehmbar: Bilder haben Textalternativen, Videos Untertitel, Text hat genug Kontrast zum Hintergrund (4,5 zu 1 für Fließtext, 3 zu 1 für großen Text und für Bedienelemente), und die Seite funktioniert auch, wenn Text auf 200 % vergrößert wird oder der Bildschirm schmal ist.
- Bedienbar: Alles lässt sich allein mit der Tastatur erledigen, der Fokus ist immer sichtbar, nichts blinkt gefährlich, bewegte Inhalte lassen sich anhalten, und Besucher haben genug Zeit zum Handeln.
- Verständlich: Die Seite gibt ihre Sprache an, die Navigation verhält sich einheitlich, Formulare haben Beschriftungen und erklären Fehler, und nichts ändert den Kontext ohne Vorwarnung.
- Robust: Der Code gibt Namen, Rollen und Zustände korrekt an assistive Technologien wie Screenreader weiter, und Statusmeldungen werden angesagt.
Nichts davon verlangt eine schlichte oder langweilige Website. Die Websites, die wir bauen, haben Bewegung, große Schrift und kräftige Farben; anders ist nur, dass Bewegung die Einstellung für reduzierte Bewegung respektiert, Farbe nie allein Bedeutung trägt und jede Interaktion einen Weg über die Tastatur hat. Barrierefreiheit funktioniert am besten als Teil der Identitätsregeln: Brand Guidelines, die barrierefreie Farbpaare festlegen, ersparen später Diskussionen.
Was sind die häufigsten Barrierefreiheitsmängel, und wie behebt man sie?
Die meisten Audits finden immer wieder dieselben Fehler. Sie entstehen aus Designentscheidungen, die ohne die Regeln getroffen wurden, und aus Komponenten, die von Projekt zu Projekt kopiert werden. Die Tabelle zeigt die, die wir am häufigsten sehen, und was sie behebt.
| Fehler | Wen es betrifft | WCAG-Kriterium | Lösung |
|---|---|---|---|
| Text mit wenig Kontrast, vor allem Grau auf Weiß oder Weiß auf kräftiger Farbe | Sehbehinderte, ältere Besucher, alle im Sonnenlicht | 1.4.3 Kontrast (Minimum) | Barrierefreie Farbpaare in den Design-Tokens festlegen und jedes neue Paar messen |
| Bilder ohne brauchbaren Alternativtext | Nutzer von Screenreadern | 1.1.1 Nicht-Text-Inhalt | Informative Bilder beschreiben; dekorativen ein leeres Alt-Attribut geben |
| Formularfelder ohne Beschriftung oder mit Platzhaltertext als einziger Beschriftung | Nutzer von Screenreadern und Sprachsteuerung | 1.3.1, 3.3.2, 4.1.2 | Eine sichtbare Beschriftung für jedes Feld; Fehler als Text neben dem Feld |
| Bedienelemente, die nur mit der Maus funktionieren | Nutzer von Tastatur und Schaltern | 2.1.1 Tastatur | Echte Buttons und Links verwenden; jeden Ablauf allein mit der Tastatur testen |
| Fokusrahmen entfernt oder hinter einem festen Header verborgen | Tastaturnutzer | 2.4.7, 2.4.11 | Ein deutlicher Fokusstil; Scroll-Abstand, damit der Fokus nie verdeckt ist |
| Überschriften für die Größe statt für die Struktur | Nutzer von Screenreadern | 1.3.1 Info und Beziehungen | Eine H1, Überschriften in der richtigen Reihenfolge, Stile per Klasse |
| Links, die nur „hier klicken“ oder „weiterlesen“ sagen | Nutzer von Screenreadern | 2.4.4 Linkzweck | Linktext, der das Ziel nennt |
| Videos ohne Untertitel | Gehörlose und schwerhörige Besucher | 1.2.2 Untertitel | Untertitel für jedes Video mit Sprache; Transkripte für Audio |
| Cookie-Banner und Pop-ups, die den Fokus festhalten oder überspringen | Nutzer von Tastatur und Screenreader | 2.1.2, 2.4.3 | Den Fokus in den Dialog setzen, dort halten und beim Schließen zurückgeben |
| Winzige Icon-Buttons dicht beieinander | Motorische Einschränkungen, Smartphone-Nutzer | 2.5.8 Zielgröße (Minimum) | Ziele von mindestens 24 mal 24 CSS-Pixeln oder Abstand um sie herum |
| Animation, die sich nicht anhalten lässt | Vestibuläre Störungen, Aufmerksamkeitsprobleme | 2.2.2 Pausieren, beenden, ausblenden | Eine Pause-Steuerung; die Einstellung für reduzierte Bewegung beachten |
Automatische Tools finden einen Teil davon, etwa fehlende Alternativtexte, schwachen Kontrast und fehlende Beschriftungen. Sie können nicht beurteilen, ob ein Alternativtext sinnvoll ist, ob die Tastaturreihenfolge Sinn ergibt oder ob eine Fehlermeldung hilft. Deshalb verbindet der folgende Ablauf Tools mit manuellen Tests.
Wie prüft und verbessert man die Barrierefreiheit einer Website?
Ein Audit nützt nur, wenn es in Korrekturen mündet und nach dem nächsten Release noch stimmt. So gehen wir vor, ob die Website von uns ist oder übernommen.
- Ziel und Umfang festlegen. Einigen Sie sich auf WCAG 2.2 AA und listen Sie die Vorlagen und Abläufe auf, die getestet werden: Startseite, eine Inhaltsseite, eine Produkt- oder Leistungsseite, Suche, Warenkorb und Checkout, Anmeldung, Kontaktformulare und Cookie-Banner. Auf den meisten Websites decken ein Dutzend Vorlagen fast jede Seite ab.
- Automatische Prüfungen laufen lassen. Nutzen Sie eine anerkannte Prüf-Engine für jede Vorlage und in jeder Sprachversion. Erfassen Sie die Probleme nach Kriterium, nicht nach Seite, denn ein Fehler in einer Komponente wiederholt sich überall.
- Allein mit der Tastatur testen. Durchlaufen Sie jeden wichtigen Ablauf ohne Maus: jedes Bedienelement erreichen, den Fokus jederzeit sehen, Menüs und Dialoge öffnen und schließen, Formulare mit und ohne Fehler absenden.
- Mit Screenreader und Zoom testen. Hören Sie die wichtigsten Abläufe mit mindestens einem Screenreader am Desktop und einem auf dem Smartphone, vergrößern Sie dann Text auf 200 % und prüfen Sie die schmale Ansicht. Kontrollieren Sie Überschriften, Landmarks, Beschriftungen und Ansagen.
- Inhalte und Medien prüfen. Kontrollieren Sie Alternativtexte, Linktexte, Untertitel, Dokumente zum Herunterladen und einfache Sprache in Anleitungen und Fehlermeldungen.
- Nach Auswirkung priorisieren. Beheben Sie zuerst, was eine Aufgabe blockiert (ein Checkout, der sich nicht per Tastatur abschließen lässt), dann, was sie erschwert, dann den Rest. Die meisten Korrekturen gehören in gemeinsame Komponenten und Design-Tokens, sodass eine Änderung viele Seiten repariert.
- Beheben, dann erneut testen. Wiederholen Sie dieselben Tests an den korrigierten Vorlagen und bewahren Sie die Ergebnisse mit Datum auf, damit Sie zeigen können, was gefunden und wann es behoben wurde.
- Die Erklärung veröffentlichen und im Release-Prozess verankern. Schreiben Sie die Erklärung zur Barrierefreiheit (siehe unten) und nehmen Sie Prüfungen der Barrierefreiheit in jedes Release auf, neben dem Rest Ihrer Website-Launch-Checkliste.
Tests mit Menschen mit Behinderungen bringen, was keine Checkliste leisten kann: ob sich die Website tatsächlich angenehm nutzen lässt. Wenn das Budget es erlaubt, ist eine kurze Runde von Sessions zu den wichtigsten Abläufen mehr wert als ein weiterer automatischer Scan.
Barrierefreiheit überschneidet sich auch mit der Wartung. Plugins und Themes, die ohne Prüfung aktualisiert werden, können Fokusführung oder Beschriftungen kaputt machen; dieselbe Disziplin, die eine Website sicher hält und die unser Leitfaden zur WordPress-Sicherheit beschreibt, hält sie also auch barrierefrei.
Brauchen Sie eine Erklärung zur Barrierefreiheit?
Nach dem European Accessibility Act müssen Dienstleister Informationen darüber bereitstellen, wie ihre Leistung die Anforderungen an die Barrierefreiheit erfüllt, in ihren Allgemeinen Geschäftsbedingungen oder an einer anderen leicht auffindbaren Stelle, und in einem barrierefreien Format. Die meisten Unternehmen lösen das mit einer Erklärung zur Barrierefreiheit, die im Footer jeder Seite verlinkt ist.
Eine klare Erklärung enthält:
- den angestrebten Standard (WCAG 2.2 AA über EN 301 549) und wie weit die Website ihn erfüllt;
- die bekannten Lücken, mit Begründung und, wo vorhanden, einem Termin für die Behebung;
- Inhalte, die von den Anforderungen ausgenommen sind, und eine eventuell dokumentierte unverhältnismäßige Belastung;
- wie und wann die Website zuletzt bewertet wurde;
- einen Kontakt, über den Besucher ein Problem melden oder Inhalte in einem anderen Format anfordern können, und wie schnell Sie antworten;
- wo sich ein Besucher beschweren kann, wenn die Antwort ihn nicht zufriedenstellt; das hängt von Ihrer nationalen Behörde ab.
Schreiben Sie sie klar und halten Sie sie aktuell. Eine Erklärung, die volle Konformität für eine Website mit offensichtlichen Fehlern behauptet, schadet mehr als eine ehrliche, die nennt, was noch behoben wird.
Wie wird der EAA durchgesetzt, und welche Strafen drohen?
Jeder Mitgliedstaat bestimmt seine eigenen Marktüberwachungsbehörden und legt eigene Sanktionen fest, die nach der Richtlinie wirksam, verhältnismäßig und abschreckend sein müssen. Behörden, Verfahren und Höhe der Sanktionen unterscheiden sich daher von Land zu Land, und manche nationalen Gesetze erlauben auch Verbraucherverbänden oder Einzelpersonen, tätig zu werden.
Für ein Unternehmen, das in mehrere EU-Länder verkauft, lautet die praktische Antwort, überall den gemeinsamen Standard zu erfüllen, statt jede nationale Abweichung zu verfolgen. Brauchen Sie die genauen Sanktionsregeln für einen Markt, lesen Sie das Umsetzungsgesetz dieses Landes oder fragen Sie einen Anwalt, der dort tätig ist: Die Beträge sind national, und wir nennen sie hier nicht.
Was die Behörden in der Regel verlangen können, sind Nachweise: der befolgte Standard, Ihre Testergebnisse, Ihre Erklärung und eine eventuelle Bewertung der unverhältnismäßigen Belastung. Die Dokumentation aus dem obigen Ablauf ist dieser Nachweis.
Häufige Fragen zur Agenturwahl
Gilt der European Accessibility Act für meine Website?
Er gilt, wenn Ihre Website oder App Verbrauchern in der EU eine erfasste Dienstleistung bietet, etwa E-Commerce, Bankdienstleistungen für Verbraucher, E-Books, elektronische Kommunikation oder Informationen zur Personenbeförderung. Eine rein informative Unternehmenswebsite kann ausgenommen sein, und Kleinstunternehmen, die Dienstleistungen erbringen, sind ausgenommen. Prüfen Sie das anhand der Liste in der Richtlinie und im Umsetzungsgesetz Ihres Landes.
Ist WCAG 2.2 AA gesetzlich vorgeschrieben?
Das Gesetz verlangt Barrierefreiheit, und die harmonisierte Norm EN 301 549 begründet eine Konformitätsvermutung. Diese Norm nutzt für Webinhalte derzeit WCAG 2.1 AA. WCAG 2.2 AA enthält diese Kriterien und fügt einige hinzu; wer nach WCAG 2.2 AA entwickelt, erfüllt also die heutige Norm und bereitet die Website auf deren nächste Fassung vor.
Kann ein Accessibility-Overlay oder Plugin meine Website konform machen?
Nein. Overlays und Toolbars ändern, wie eine Seite aussieht oder vorgelesen wird, beheben aber nicht den zugrunde liegenden Code, die Beschriftungen, die Tastaturreihenfolge oder die Inhalte, und manche stören die Screenreader, die Besucher bereits nutzen. Eine konforme Website braucht korrigierte Vorlagen und Komponenten. Plugins können beim Prüfen während der Bearbeitung helfen, ersetzen die Arbeit aber nicht.
Wie lange dauert ein Audit zur Barrierefreiheit einer Website?
Das hängt von der Zahl der Vorlagen und Abläufe ab, nicht von der Zahl der Seiten, denn die meisten Fehler stecken in gemeinsamen Komponenten. Eine kleine Website mit wenigen Vorlagen lässt sich schnell prüfen; ein umfangreicher Shop mit Konten, Suche und Checkout dauert länger. Einen festen Plan gibt es nach einem kurzen Blick auf die Website und ihre wichtigsten Abläufe.
Was passiert, wenn meine Website nicht barrierefrei ist?
Sie riskieren Maßnahmen der nationalen Marktüberwachungsbehörde, die nach nationalem Recht Korrekturen verlangen und Sanktionen verhängen kann, und in manchen Ländern Beschwerden von Verbrauchern oder Verbänden. Ebenso wichtig: Sie verlieren Kunden, die einen Kauf nicht abschließen können. Beheben Sie zuerst die blockierenden Probleme und veröffentlichen Sie eine ehrliche Erklärung, während der Rest erledigt wird.
Wenn Sie nicht sicher sind, ob Ihre Website den European Accessibility Act erfüllt, beginnen Sie mit einem Audit der Vorlagen und Abläufe, die am meisten zählen, und beheben Sie dann die gemeinsamen Komponenten, die die meisten Fehler verursachen. Wir bauen barrierefreie Websites ab dem ersten Wireframe und reparieren übernommene im Rahmen unserer Arbeit in Webdesign und Webentwicklung. Sprechen Sie mit uns über Ihre Website, und wir sagen Ihnen klar, wo sie steht.
Weiterlesen: Checkliste für UX-Audits: was Sie prüfen sollten und wie ein Audit in sieben Schritten abläuft.
