Website auf Barrierefreiheit prüfen: automatische Tests, Tastatur, Screenreader und Kontrast

Der Maßstab: WCAG, EN 301 549, BFSG und BITV 2.0

Fachlicher Maßstab für barrierefreie Websites sind die Web Content Accessibility Guidelines (WCAG) des W3C. Die aktuelle Fassung WCAG 2.2 ordnet ihre Erfolgskriterien vier Prinzipien zu: wahrnehmbar, bedienbar, verständlich und robust. Jedes Kriterium gehört zu einer von drei Stufen: A (niedrigste), AA und AAA (höchste). Die Kriterien sind prüfbar formuliert, etwa als Mindestkontrast von 4,5:1 für normalen Text, und eignen sich deshalb als Grundlage für jede Prüfung.

Was BFSG und BITV 2.0 regeln

Mit dem Barrierefreiheitsstärkungsgesetz (BFSG) setzt Deutschland die Richtlinie (EU) 2019/882 über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen um, den European Accessibility Act (EAA). Das Gesetz gilt für bestimmte Produkte, die nach dem 28. Juni 2025 in Verkehr gebracht werden, und für bestimmte Dienstleistungen, die nach diesem Datum für Verbraucher erbracht werden. Zu diesen Dienstleistungen zählen nach § 1 Abs. 3 Nr. 5 BFSG Dienstleistungen im elektronischen Geschäftsverkehr, zum Beispiel Online-Shops.

Nach den FAQ der Bundesfachstelle Barrierefreiheit fällt eine Website unter das Gesetz, wenn über sie Dienstleistungen aus diesem Anwendungsbereich für Verbraucher angeboten werden, etwa Online-Banking oder Dienstleistungen im elektronischen Geschäftsverkehr. Letztere werden nach § 2 Nr. 26 BFSG auf individuelle Anfrage eines Verbrauchers im Hinblick auf den Abschluss eines Verbrauchervertrags erbracht, zum Beispiel bei einer Bestellung im Online-Shop; als weiteres Beispiel nennen die Leitlinien des BMAS laut Bundesfachstelle die Online-Buchung von Terminen. Eine reine Präsentationswebsite, die nur informiert oder Produkte und Dienstleistungen bewirbt, sollte danach nicht betroffen sein, ebenso wenig Dienstleistungen, die ausschließlich anderen Unternehmen (B2B) angeboten werden. Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen, sind von den Anforderungen ausgenommen (§ 3 Abs. 3 BFSG). Als Kleinstunternehmen gilt nach § 2 Nr. 17 BFSG ein Unternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme. Die Marktüberwachung liegt bei den Ländern; nach Angaben der Bundesfachstelle hat dafür am 26. September 2025 die gemeinsame Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) in Magdeburg ihre Arbeit aufgenommen.

Für Websites, mobile Anwendungen und elektronisch unterstützte Verwaltungsabläufe öffentlicher Stellen des Bundes gilt die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0). Sie verweist in § 3 auf harmonisierte Normen und regelt in § 7 die Erklärung zur Barrierefreiheit. Als derzeit maßgebliche harmonisierte Norm nennt die Bundesfachstelle die EN 301 549 V3.2.1 (2021-03).

Auch für das BFSG bezeichnet die Bundesfachstelle die EN 301 549 als zentrale technische Referenz. Die Anforderungen an Websites stehen in Abschnitt 9 und in Tabelle A.1 im Anhang der Norm. Für Webinhalte übernimmt die Norm nach Angaben des W3C die WCAG 2.1 auf Stufe AA unverändert, also die Kriterien der Stufen A und AA. Eine aktualisierte Fassung der Norm wird laut Bundesfachstelle auf WCAG 2.2 verweisen. Für die praktische Prüfung bieten sich deshalb die Kriterien der Stufen A und AA als Arbeitsmaßstab an.

Dieser Leitfaden ist keine Rechtsberatung. Die rechtlichen Angaben beziehen sich auf Deutschland; in Österreich und der Schweiz gelten eigene Regelungen. Ob ein Angebot unter das BFSG fällt, hängt vom Einzelfall ab. Kein Prüfwerkzeug kann allein feststellen, dass eine Website die gesetzlichen Anforderungen erfüllt.

Formulare prüfen: Labels, Namen und Fehlermeldungen

Formulare sind im Shop die Stellen, an denen ein Kauf scheitern kann: Suche, Adresseingabe, Auswahl der Zahlungsart, Newsletter-Anmeldung. Prüfen Sie zuerst, ob jedes Eingabefeld ein sichtbares Label hat und ob dieses im Code mit dem Feld verknüpft ist. Beim label-Element muss der Wert von for exakt der id des Feldes entsprechen; alternativ umschließt das label-Element das Feld. Ein schneller Test: Klicken Sie auf den Label-Text. Springt der Cursor ins Feld, ist die Verknüpfung vorhanden.

Ein Platzhaltertext im Feld ersetzt kein Label, denn er verschwindet, sobald jemand tippt. Auch Schaltflächen und Links brauchen einen Namen, der die Aktion beschreibt: „Suche starten“ statt einer Lupe ohne Namen, „Adresse speichern“ statt „OK“. Welchen Namen der Browser an assistive Technologien weitergibt, zeigen die Entwicklertools. In Chrome markieren Sie das Element in den Entwicklertools und öffnen den Tab für Barrierefreiheit (englisch „Accessibility“); der Name steht dort unter den berechneten Eigenschaften (englisch „Computed Properties“).

Danach provozieren Sie Fehler: Lassen Sie ein Pflichtfeld leer, geben Sie eine E-Mail-Adresse ohne @ ein und senden Sie das Formular ab. WCAG verlangt auf Stufe A, dass bei einem automatisch erkannten Eingabefehler das betroffene Feld kenntlich gemacht und der Fehler in Textform beschrieben wird (Kriterium 3.3.1). Eine rote Umrandung allein genügt dafür nicht. Bewährt hat sich eine Meldung direkt am Feld, die per aria-describedby mit dem Feld verknüpft ist, bei längeren Formularen zusätzlich eine Fehlerübersicht über dem Formular, die jedes betroffene Feld beim Namen nennt und dorthin verlinkt. Bereits eingegebene Daten sollten nach dem Absenden erhalten bleiben.

Tastaturtest: Tab, sichtbarer Fokus und keine Falle

Legen Sie die Maus beiseite und gehen Sie den Kaufablauf nur mit der Tastatur durch. Mit Tab springen Sie vorwärts, mit Umschalt+Tab zurück. Enter löst Links und Schaltflächen aus, die Leertaste Schaltflächen und Kontrollkästchen. Mit den Pfeiltasten bewegen Sie sich in Auswahllisten und Optionsgruppen, mit Escape sollten sich Dialoge schließen lassen. WCAG-Kriterium 2.1.1 (Stufe A) verlangt, dass sich alle Funktionen per Tastatur bedienen lassen.

Achten Sie dabei auf folgende Punkte:

• Sichtbarer Fokus: An jeder Stelle muss erkennbar sein, wo der Tastaturfokus steht (Kriterium 2.4.7, Stufe AA). Eine häufige Ursache für Probleme: Die Fokusumrandung (outline) wurde per CSS entfernt, ohne einen anderen Fokusstil festzulegen.
• Logische Reihenfolge: Der Fokus folgt der Lesereihenfolge. Positive tabindex-Werte bringen sie oft durcheinander.
• Keine Tastaturfalle: Aus jedem Element muss man per Tastatur wieder herauskommen (Kriterium 2.1.2, Stufe A). Prüfen Sie besonders eingebettete Karten, Videoplayer und Chat-Widgets.
• Dialoge: Öffnet sich ein Dialog, etwa der Hinweis „Artikel liegt im Warenkorb“, gehört der Fokus hinein. Nach dem Schließen kehrt er an eine sinnvolle Stelle zurück, meist zum auslösenden Element.
• Fokus nicht verdeckt: Fixierte Kopfzeilen, Chat-Schaltflächen oder Banner dürfen das fokussierte Element nicht vollständig verdecken (Kriterium 2.4.11, Stufe AA, neu in WCAG 2.2).

Ein Link „Zum Inhalt springen“ als erstes fokussierbares Element erspart allen, die per Tastatur navigieren, auf jeder Seite die komplette Navigation zu durchlaufen. Auch das Cookie-Banner gehört zum Test: Lässt es sich ohne Maus bedienen und schließen, und landet der Fokus danach an einer sinnvollen Stelle?

Struktur und Alternativtexte prüfen

Mit einem Screenreader kann man von Überschrift zu Überschrift springen; die Überschriftenstruktur dient dann als Inhaltsverzeichnis der Seite. Prüfen Sie deshalb, ob es eine h1 mit dem Thema der Seite gibt, ob h2 und h3 logisch darauf aufbauen, ob die Überschriftenebenen nach der Gliederung und nicht nach der Schriftgröße gewählt wurden und ob wichtige Zwischentitel als echte Überschriften ausgezeichnet sind statt nur fett formatiert. Ebenfalls zu prüfen sind ein aussagekräftiger Seitentitel im title-Element, die Sprache der Seite im lang-Attribut, zum Beispiel <html lang="de">, und Landmarks wie main und nav.

Bei Bildern zählt nicht nur, ob ein alt-Attribut vorhanden ist, sondern ob der Text zum Zweck des Bildes passt. Der Entscheidungsbaum aus den W3C-Tutorials unterscheidet mehrere Fälle:

• Informative Bilder wie ein Produktfoto: Der Alternativtext beschreibt, was für die Kaufentscheidung zählt, etwa „Rucksack in Dunkelgrün, Vorderansicht mit zwei Seitentaschen“ statt „IMG_2048.jpg“.
• Funktionale Bilder in Links oder Schaltflächen: Der Alternativtext nennt Ziel oder Aktion, etwa „Startseite“ für das verlinkte Logo oder „Suche“ für die Lupe.
• Dekorative Bilder bekommen ein leeres alt="", damit Screenreader sie überspringen.
• Komplexe Grafiken, etwa eine Größentabelle als Bild, brauchen eine kurze Kernaussage im Alternativtext und die vollständige Information als Text oder echte Tabelle in der Nähe.

Ein automatischer Test meldet fehlende alt-Attribute. Ob „Bild“ oder „Produktfoto“ als Alternativtext etwas aussagt, beurteilt nur ein Mensch.

Kontrast, Zoom und Reflow messen

Für Textkontrast gilt auf Stufe AA ein Verhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (Kriterium 1.4.3). Als groß gilt Text ab 18 Punkt oder ab 14 Punkt fett; das entspricht laut W3C etwa 24 bzw. 18,5 CSS-Pixeln. Ausgenommen sind unter anderem Logos, reine Dekoration und inaktive Bedienelemente. Messen Sie die tatsächlich dargestellten Farben, zum Beispiel mit der Kontrastanzeige in der Farbauswahl der Chrome-Entwicklertools oder mit einem Kontrastrechner. Kritisch sind Text auf Fotos und Farbverläufen, hellgraue Hinweistexte sowie Hover- und Fokuszustände.

Für Bedienelemente und Grafiken verlangt Kriterium 1.4.11 (Stufe AA) einen Kontrast von mindestens 3:1 zu angrenzenden Farben, soweit die visuelle Information nötig ist, um das Element und seinen Zustand zu erkennen. Das betrifft etwa Rahmen von Eingabefeldern, Icons ohne Text und den Fokusindikator.

Danach folgen Zoom und Reflow:

• Textvergrößerung: Text muss sich ohne assistive Technologien auf 200 Prozent vergrößern lassen, ohne dass Inhalte oder Funktionen verloren gehen (Kriterium 1.4.4, Stufe AA). Prüfen Sie im Quelltext auch, ob der viewport-Meta-Tag das Zoomen mit user-scalable=no sperrt.
• Reflow: Stellen Sie das Browserfenster auf 1280 CSS-Pixel Breite und zoomen Sie auf 400 Prozent. Das entspricht laut W3C einer Breite von 320 CSS-Pixeln. Inhalte müssen dann lesbar und bedienbar bleiben, ohne dass in zwei Richtungen gescrollt werden muss (Kriterium 1.4.10, Stufe AA). Ausgenommen sind Inhalte, die ein zweidimensionales Layout brauchen, etwa Datentabellen oder Karten.

Achten Sie bei dieser Vergrößerung auch darauf, dass fixierte Kopfzeilen, Chat-Schaltflächen und Banner nicht den halben Bildschirm belegen und Inhalte verdecken.

Automatische Tests richtig einordnen

Automatische Prüfwerkzeuge, ob als Browser-Erweiterung, in den Entwicklertools oder als Onlinedienst, lesen den Code und melden Muster, die sich maschinell erkennen lassen. Sie sind ein guter Einstieg und eignen sich, um nach jedem Release dieselben Punkte erneut zu prüfen. Das W3C hält fest, dass Werkzeuge Barrierefreiheit nicht feststellen, sondern nur bei der Prüfung helfen können. Manche Ergebnisse können falsch oder irreführend sein, und menschliches Urteil bleibt nötig.

Ein Ergebnis ohne Befunde bedeutet deshalb nur, dass die maschinell prüfbaren Muster unauffällig sind. Das W3C formuliert es für seine eigenen „Easy Checks“ ähnlich: Eine Seite kann diese Schnelltests scheinbar bestehen und trotzdem erhebliche Barrieren haben.

Screenreader-Test und ein wiederholbarer Prüfablauf

Für den Screenreader-Test brauchen Sie keine kostenpflichtige Software: NVDA ist ein kostenloser Screenreader für Windows, VoiceOver ist in macOS integriert. Nehmen Sie sich die wichtigsten Seiten vor und prüfen Sie Folgendes:

• Überblick: Lassen Sie sich die Liste der Überschriften und Links anzeigen. Ist die Seite allein daraus verständlich? Linktexte wie „hier“ oder „mehr“ fallen in dieser Liste sofort auf.
• Formulare: Wird zu jedem Feld der Name vorgelesen, und hört man die Fehlermeldung nach dem Absenden?
• Änderungen auf der Seite: Legen Sie einen Artikel in den Warenkorb, setzen Sie einen Filter, öffnen Sie einen Dialog. Bekommt man ohne Blick auf den Bildschirm mit, dass sich etwas geändert hat?

Damit die Prüfung wiederholbar wird, bestimmen Sie eine feste Stichprobe: Startseite, eine Kategorieseite, eine Produktseite, Warenkorb, Kasse, Kontaktformular und Seiten mit selbst entwickelten Komponenten. Notieren Sie zu jedem Befund Seite, Komponente, betroffenes WCAG-Kriterium sowie beobachtetes und erwartetes Verhalten. Viele Probleme stecken in gemeinsam genutzten Komponenten: Wer einen Fehler im Formularfeld des Designsystems behebt, behebt ihn auf allen Seiten, die dieses Feld verwenden.

Für eine umfassende Prüfung auf Grundlage von BITV 2.0, EN 301 549 und WCAG gibt es Verfahren mit festgelegten Prüfschritten. Welche Normen und Standards dabei maßgeblich sind, erläutert die Bundesfachstelle Barrierefreiheit. Rückmeldungen von Menschen, die selbst mit Screenreader, Vergrößerung oder Tastatur arbeiten, zeigen außerdem Probleme, die keine Checkliste erfasst.

Was die Barrierefreiheitsprüfung von Sitelemetry abdeckt

Sitelemetry enthält eine Barrierefreiheitsprüfung als einen von sechs Audit-Bereichen: Sicherheit, technisches SEO, KI-Sichtbarkeit, Barrierefreiheit, Performance und Integrationen. Die Prüfung lädt das HTML einer einzelnen URL und analysiert es statisch. Die Seite wird nicht im Browser gerendert, JavaScript wird nicht ausgeführt.

Geprüft werden Alternativtexte von Bildern, Formular-Labels und Namen von Bedienelementen, die Reihenfolge der Überschriften und leere Überschriften, ein main-Landmark, das lang-Attribut, der Seitentitel, doppelte IDs, Titel von iframes, Tabellenüberschriften, positive tabindex-Werte, Meta-Refresh, ein viewport-Meta-Tag, der das Zoomen sperrt, automatisch startende Medien und ein Skip-Link. Kontrast wird nur dort bewertet, wo Inline-Styles sowohl Text- als auch Hintergrundfarbe setzen.

Der ausgegebene Wert ist keine WCAG-Konformitätsstufe und keine Bewertung nach BFSG oder BITV 2.0. Kontrast im Allgemeinen, Tastaturbedienung, sichtbarer Fokus, Reflow, Zielgrößen und dynamisches Verhalten müssen im Browser und von Hand geprüft werden, wie in den Abschnitten oben beschrieben. Die Prüfung eignet sich, um Markup-Fehler nach Änderungen schnell wiederzufinden, etwa nach einem Theme-Update.

Die Barrierefreiheitsprüfung ist ab dem Starter-Plan für 49 US-Dollar im Monat enthalten, zusammen mit den übrigen fünf Audit-Bereichen; der Free-Plan umfasst nur Sicherheitsprüfungen (siehe Preise). Über den MCP-Server lässt sich die Prüfung auch aus MCP-Clients wie ChatGPT, Claude, Cursor oder Codex heraus starten, siehe die MCP-Anleitung. Der kostenlose Snapshot prüft dagegen keine Barrierefreiheit: Er führt ohne Anmeldung acht passive Prüfungen zu DNS, E-Mail-DNS-Einträgen, Domainregistrierung, TLS und der HTTP-Antwort der Startseite aus und ist nicht das Audit mit sechs Bereichen.