BFSG-Checkliste: der European Accessibility Act für Websites

1. Klären, ob es dich betrifft

Die Richtlinie erfasst Dienstleistungen für Verbraucher: E-Commerce, Bankdienstleistungen, E-Books, elektronische Kommunikation, Zugang zu audiovisuellen Mediendiensten und Personenbeförderung. Für die meisten Website-Betreiber geht es um E-Commerce — jede Website, auf der Verbraucher online kaufen oder buchen, vom WooCommerce-Shop bis zum Buchungsformular mit Bezahlung.

Kleinstunternehmen, die Dienstleistungen erbringen, sind ausgenommen: weniger als 10 Beschäftigte und ein Jahresumsatz oder eine Jahresbilanzsumme von höchstens 2 Mio. €. Darüber kannst du für einzelne Anforderungen eine unverhältnismäßige Belastung geltend machen, musst sie aber bewerten, dokumentieren und regelmäßig überprüfen — ein Freibrief ist das nicht.

Jedes Land hat die Richtlinie in eigenes Recht umgesetzt, mit eigenen Behörden und Sanktionen. Unsere Seite zum Barrierefreiheitsstärkungsgesetz fasst das Gesetz und zwei nationale Bußgeldregelungen mit Quellen zusammen.

2. Wissen, was das Gesetz von einer Website verlangt

Anhang I der Richtlinie verlangt, dass Websites und Apps wahrnehmbar, bedienbar, verständlich und robust sind. Das sind die vier Prinzipien der WCAG, der Web Content Accessibility Guidelines des W3C — und so wird die Anforderung in der Praxis erfüllt: über die EN 301 549, die europäische Norm, deren Web-Teil den WCAG folgt.

EN 301 549 Version 3.2.1 folgt WCAG 2.1 Stufe AA. Version 4.1.1, im September 2026 im Rahmen des Normungsauftrags zum EAA aktualisiert, geht zu WCAG 2.2 Stufe AA über. Wenn du jetzt anfängst, zielst du auf 2.2 AA: Das ist 2.1 plus einige Kriterien wie eine Mindestgröße für Klickziele und Fokus, der nicht hinter einem fixierten Header verschwindet.

Das Gesetz verlangt auch Informationen. Nach Anhang V erklären Dienstleister, wie ihr Dienst die Anforderungen an die Barrierefreiheit erfüllt — meist in einer Erklärung zur Barrierefreiheit, die den angestrebten Standard, bekannte Lücken und den Weg zum Melden eines Problems nennt.

3. Die Seiten testen, mit denen du Geld verdienst

Beginne mit den Seiten, durch die Kunden müssen: Startseite, eine Kategorie, ein Produkt, Warenkorb, Checkout sowie Anmeldung oder Konto. Eine automatische Engine wie axe-core — die Grundlage von axe DevTools und des Barrierefreiheitswerts in Lighthouse — findet die maschinell erkennbaren WCAG-Fehler in Sekunden: fehlende Labels, fehlende Alt-Texte, zu wenig Kontrast, Buttons ohne Namen, fehlende Seitensprache.

Behebe zuerst den Checkout. Ein E-Mail-Feld ohne Label oder ein Bezahl-Button ohne Namen kann Screenreader-Nutzer komplett am Kauf hindern; ein Kontrastproblem im Footer nicht. Die Tabelle unten listet die häufigsten Fehler nach WCAG-Kriterium und zeigt, welche ein Tool findet.

4. Von einem Menschen testen lassen, was Tools nicht können

Automatisierte Tests finden einen Teil der Probleme, nicht alle. Das W3C stellt klar, dass Testwerkzeuge Barrierefreiheit allein nicht feststellen können, und Deques Studie realer Audits ergab, dass automatisierte Tests rund 57 % der Probleme (nach Anzahl) fanden. Der Rest braucht Urteilsvermögen.

Mach das von Hand: den ganzen Checkout nur mit der Tastatur durchgehen und darauf achten, dass du immer siehst, wo du bist; auf 200 % zoomen und sicherstellen, dass nichts abgeschnitten wird; einen Screenreader einschalten (VoiceOver und NVDA sind kostenlos) und einen Kauf abschließen; ein Formular mit Fehlern absenden und lesen, ob die Meldungen sagen, was zu korrigieren ist. Für eine Website im Anwendungsbereich lohnt sich ein professionelles Audit — idealerweise mit Menschen, die assistive Technologien nutzen.

5. Rückschritte verhindern

Diesen Schritt lassen die meisten Checklisten weg. Barrierefreiheit ist nicht einmal erledigt: Ein Theme-Update schreibt das Checkout-Markup neu, ein Page Builder ersetzt einen Button durch ein Icon, eine neue Kampagnenfarbe unterschreitet den Kontrast. Nichts davon erscheint als Fehler, und niemand wiederholt nach jedem Plugin-Update das Audit.

Das Barrierefreiheit-Monitoring von Relvato führt dieselben axe-core-Regeln wöchentlich und nach Plugin-, Theme-, Core- und WooCommerce-Updates auf deinen wichtigsten Seiten aus. Du bestätigst die Probleme des ersten Scans als Baseline; danach lässt jedes neue Problem den Lauf fehlschlagen und nennt Seite und WCAG-Kriterium — solange die Korrektur noch klein ist.