Barrierefreiheit: 6 Prüfkriterien der Website-Analyse

Eine barrierefreie Website lässt sich von allen Menschen nutzen – auch von Menschen, die nicht sehen, nicht hören, keine Maus bedienen können oder Inhalte vergrößern müssen. Barrierefreiheit betrifft aber nicht nur Menschen mit Behinderungen. Wer mit dem Smartphone in der Sonne steht, einen Arm gebrochen hat oder mit zunehmendem Alter schlechter sieht, profitiert von denselben Maßnahmen: klaren Kontrasten, verständlicher Struktur, ausreichend großen Bedienelementen und einer Website, die sich auch per Tastatur bedienen lässt.

Bedienbar auch ohne Maus. Beschriftete Felder, eine logische Reihenfolge und ein sichtbarer Fokus machen ein Formular per Tastatur und mit Hilfstechnik nutzbar.

Die W3C Web Accessibility Initiative beschreibt Barrierefreiheit deshalb als Qualitätsmerkmal, das neben der Teilhabe auch Reichweite, Nutzbarkeit und Vertrauen in eine Marke stärkt (W3C WAI: The Business Case for Digital Accessibility). Seit dem 28. Juni 2025 ist sie für viele verbraucherorientierte Online-Angebote in Deutschland zudem gesetzlich vorgeschrieben.

Auf einen Blick

  • Geprüft werden Tastaturbedienung und sichtbarer Fokus, semantische Struktur, Alternativtexte, Kontraste, Formularbeschriftungen sowie ein automatisierter Accessibility-Scan.
  • Maßstab sind die Web Content Accessibility Guidelines (WCAG) 2.2 des W3C in der Fassung vom 12. Dezember 2024 auf den Stufen A und AA; WCAG 2.2 ist zugleich als internationale Norm ISO/IEC 40500:2025 veröffentlicht (W3C: WCAG 2.2, W3C WAI: WCAG 2 Overview).
  • Die Prüfung arbeitet mit Stichproben. Sie zeigt Barrieren auf, ist aber keine vollständige Konformitätsprüfung und keine Rechtsberatung.
  • Laut WebAIM hatten im Februar 2026 95,9 % der eine Million meistbesuchten Startseiten automatisch erkennbare WCAG-Fehler (WebAIM: The WebAIM Million).

Rechtlicher Rahmen: BFSG, EN 301 549 und WCAG

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act in deutsches Recht um und gilt seit dem 28. Juni 2025. Es verpflichtet Wirtschaftsakteure, bestimmte Produkte und Dienstleistungen barrierefrei anzubieten (BFSG § 3). Zu den erfassten Dienstleistungen gehören nach § 1 Abs. 3 BFSG unter anderem Dienstleistungen im elektronischen Geschäftsverkehr, die für Verbraucher erbracht werden (BFSG § 1). Das Gesetz definiert sie in § 2 Nr. 26 als digitale Dienste im Sinne des Digitale-Dienste-Gesetzes, die über Websites und mobile Anwendungen elektronisch und auf individuelle Anfrage eines Verbrauchers im Hinblick auf den Abschluss eines Verbrauchervertrags erbracht werden – typischerweise Online-Shops, Buchungsstrecken oder Online-Vertragsabschlüsse (BFSG § 2).

Ausnahme für Kleinstunternehmen: Die Pflicht gilt nicht für Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen (§ 3 Abs. 3 BFSG). Als Kleinstunternehmen gelten nach § 2 Nr. 17 BFSG Unternehmen mit weniger als zehn Beschäftigten und einem Jahresumsatz oder einer Jahresbilanzsumme von höchstens 2 Millionen Euro. Für Produkte gilt diese Ausnahme nicht (BFSG § 2, BFSG § 3). Für öffentliche Stellen gelten eigene Vorgaben, insbesondere die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0).

Marktüberwachung: Zuständig für die Marktüberwachung nach dem BFSG ist seit dem 26. September 2025 die Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) mit Sitz in Magdeburg, die die Länder per Staatsvertrag gemeinsam errichtet haben (Land Schleswig-Holstein: MLBF). Seit Juni 2026 informiert sie auf einer eigenen Website über Pflichten von Unternehmen und nimmt Hinweise auf Barrieren entgegen (Bundesfachstelle Barrierefreiheit: Website der Marktüberwachungsstelle ist online).

Der technische Maßstab ist die europäische Norm EN 301 549, die für Webinhalte auf die WCAG verweist. Am 2. September 2026 haben ETSI, CEN und CENELEC die neue Fassung EN 301 549 V4.1.1 veröffentlicht; sie richtet die Anforderungen für Webinhalte, Dokumente und Software an WCAG 2.2 aus und ordnet sie in einem eigenen Anhang auch der Richtlinie (EU) 2019/882 zu, die das BFSG umsetzt (ETSI: EN 301 549 V4.1.1). Eine Vermutungswirkung entfaltet die Norm erst, wenn ihre Fundstelle im Amtsblatt der EU veröffentlicht ist; das ist nach unserem Kenntnisstand (November 2026) noch nicht geschehen und wird für Ende 2026 erwartet (National Disability Authority: EN 301 549 V4.1.1 published). Für Websites öffentlicher Stellen ist bis dahin die Fassung V3.2.1 auf Basis von WCAG 2.1 als harmonisierte Norm maßgeblich (EUR-Lex: Durchführungsbeschluss (EU) 2021/1339). Für neue Projekte ist WCAG 2.2 AA damit das sinnvolle Ziel. Die nächste Generation, WCAG 3.0, liegt bislang nur als Arbeitsentwurf vor, zuletzt vom 10. September 2026 (W3C: Versionsgeschichte WCAG 3.0).

Ob Ihre Website unter das BFSG fällt, hängt vom Angebot, der Zielgruppe und der Unternehmensgröße ab und ist eine rechtliche Einzelfallfrage. Unsere Analyse liefert technische Hinweise auf Barrieren, aber keine rechtliche Bewertung.

Warum Stichproben – und warum nicht nur ein Scan

Automatische Werkzeuge finden viele Fehler schnell, aber nicht alle. WebAIM, das jährlich die Startseiten der eine Million meistbesuchten Websites automatisch prüft, betont selbst: Werden keine Fehler erkannt, heißt das nicht, dass eine Seite barrierefrei oder konform ist (WebAIM: The WebAIM Million). Auch die W3C Web Accessibility Initiative weist darauf hin, dass kein Werkzeug allein feststellen kann, ob eine Website die Anforderungen erfüllt; dafür ist die Prüfung durch Fachleute nötig (W3C WAI: Evaluating Web Accessibility, W3C WAI: Web Accessibility Evaluation Tools List).

Deshalb kombiniert die Analyse einen automatisierten Scan mit gezielten manuellen Stichproben: Tastaturbedienung, Struktur, Bildbeschreibungen, Kontraste und Formulare werden direkt auf repräsentativen Seiten untersucht.

Die WebAIM-Daten zeigen, wo die häufigsten Probleme liegen. Im Februar 2026 betrafen sechs Fehlerarten 96 % aller erkannten Fehler: zu geringer Textkontrast (83,9 % der Startseiten), fehlende Alternativtexte für Bilder (53,1 %), fehlende Formularbeschriftungen (51 %), leere Links (46,3 %), leere Schaltflächen (30,6 %) und eine fehlende Sprachangabe des Dokuments (13,5 %). Im Durchschnitt fanden sich 56,1 erkennbare Fehler pro Startseite (WebAIM: The WebAIM Million). Viele davon lassen sich mit vergleichsweise geringem Aufwand beheben.

Prüfkriterien im Detail

Tastatur & sichtbarer Fokus

Worum es geht. Geprüft wird, ob sich Navigation, Links, Schaltflächen, Menüs, Dialoge und Formulare ausschließlich mit der Tastatur bedienen lassen und ob jederzeit sichtbar ist, welches Element gerade ausgewählt ist.

Warum das wichtig ist. Viele Menschen bedienen Websites ohne Maus: blinde Menschen mit Screenreader, Menschen mit motorischen Einschränkungen oder Nutzer, die per Tastatur schlicht schneller arbeiten. Die WCAG verlangen, dass alle Funktionen per Tastatur bedienbar sind (Erfolgskriterium 2.1.1). Ausgenommen sind nur Funktionen, die vom Bewegungspfad abhängen, etwa Freihandzeichnen. Der Tastaturfokus muss sichtbar sein (2.4.7). Neu in WCAG 2.2 ist das Kriterium 2.4.11: Das fokussierte Element darf nicht vollständig von anderen Inhalten verdeckt werden, etwa von einer fixierten Kopfzeile oder einem Cookie-Banner (W3C: Understanding Keyboard, W3C: Understanding Focus Not Obscured (Minimum)).

So prüfen wir. Auf repräsentativen Seiten werden die interaktiven Elemente mit der Tabulatortaste durchlaufen. Dokumentiert werden Erreichbarkeit, Reihenfolge, Sichtbarkeit des Fokus und mögliche Tastaturfallen, aus denen man nicht mehr herauskommt.

Typische Befunde.

  • Die Fokusmarkierung wurde per CSS entfernt (outline: none), ohne Ersatz.
  • Aufklappmenüs öffnen sich nur bei Mausberührung.
  • Ein Cookie-Banner oder Dialog lässt sich per Tastatur nicht schließen.
  • Der Fokus verschwindet hinter einer fixierten Kopfzeile.

Was Sie tun können. Stellen Sie sicher, dass jedes interaktive Element einen deutlich sichtbaren Fokuszustand hat, und verwenden Sie echte HTML-Elemente wie button und a, die von sich aus per Tastatur bedienbar sind. Testen Sie selbst: Bedienen Sie Ihre Startseite fünf Minuten lang nur mit Tabulator, Eingabe- und Leertaste.

Grenzen der Aussage. Eine Stichprobe belegt keine WCAG-Konformität der gesamten Website.

Semantische Struktur & Landmarks

Worum es geht. Untersucht wird, ob die HTML-Struktur die inhaltliche Gliederung abbildet: Überschriftenhierarchie, Seitenbereiche wie Kopfbereich, Navigation, Hauptinhalt und Fußbereich (Landmarks), Listen, Tabellen und die Sprachangabe der Seite.

Warum das wichtig ist. Screenreader-Nutzer springen über Überschriften und Seitenbereiche durch eine Seite, ähnlich wie sehende Menschen sie überfliegen. Das funktioniert nur, wenn die Struktur im Code ausgezeichnet ist. Die WCAG verlangen, dass Informationen und Beziehungen, die visuell vermittelt werden, auch programmatisch erkennbar sind (Erfolgskriterium 1.3.1), und dass die Sprache der Seite angegeben wird (3.1.1) (W3C: WCAG 2.2, W3C WAI: Page Structure – Headings, W3C WAI: Landmark Regions). Eine saubere Struktur hilft zugleich Suchmaschinen und KI-Systemen, Inhalte zu verstehen.

So prüfen wir. Im HTML ausgewählter Seiten werden Überschriftenebenen, Landmarks, Beschriftungen und die Sprachangabe untersucht.

Typische Befunde.

  • Überschriften-Tags werden nach Schriftgröße statt nach inhaltlicher Ebene vergeben.
  • Fehlende main- oder nav-Bereiche.
  • Kein lang-Attribut, sodass Screenreader den Text mit falscher Aussprache vorlesen.
  • Leere Links oder Schaltflächen, etwa reine Symbole ohne Textalternative.

Was Sie tun können. Vergeben Sie Überschriften nach inhaltlicher Hierarchie, verwenden Sie die HTML-Elemente header, nav, main und footer und setzen Sie die Sprachangabe, etwa lang="de". Geben Sie Symbol-Schaltflächen einen zugänglichen Namen.

Grenzen der Aussage. Eine korrekte Struktur in der Stichprobe belegt keine WCAG-Konformität.

Alternativtexte im Stichprobenumfang

Worum es geht. Geprüft wird, ob informative Bilder eine sinnvolle Textalternative haben und dekorative Bilder so ausgezeichnet sind, dass Screenreader sie überspringen.

Warum das wichtig ist. Für blinde und stark sehbehinderte Menschen ist der Alternativtext die einzige Information, die ein Bild vermittelt. Die WCAG verlangen für alle Nicht-Text-Inhalte eine Textalternative, die denselben Zweck erfüllt (Erfolgskriterium 1.1.1) (W3C: Understanding Non-text Content). Fehlende Alternativtexte gehören laut WebAIM zu den häufigsten Barrieren überhaupt (WebAIM: The WebAIM Million).

So prüfen wir. Repräsentative Bilder werden danach eingeordnet, ob sie informativ, funktional (etwa ein verlinktes Logo) oder dekorativ sind, und ihre Alternativtexte werden auf Zweckmäßigkeit geprüft.

Typische Befunde.

  • Fehlende alt-Attribute.
  • Alternativtexte wie „Bild1“ oder Dateinamen.
  • Verlinkte Logos oder Symbole ohne Beschreibung des Linkziels.
  • Diagramme und Infografiken ohne Erläuterung der dargestellten Information.

Was Sie tun können. Beschreiben Sie, welche Information ein Bild vermittelt – kurz und im Kontext. Für dekorative Bilder setzen Sie ein leeres Alternativattribut (alt=""). Bei verlinkten Bildern beschreiben Sie das Linkziel. Der Entscheidungsbaum der W3C WAI hilft bei der Einordnung (W3C WAI: Images Tutorial).

Grenzen der Aussage. Eine Stichprobe belegt nicht die Qualität aller Alternativtexte einer Website.

Kontrast-Stichprobe

Worum es geht. Gemessen wird das Kontrastverhältnis zwischen Text und Hintergrund sowie bei Bedienelementen und informativen Grafiken.

Warum das wichtig ist. Zu geringer Kontrast macht Inhalte für Menschen mit Sehschwäche schwer lesbar – und für alle anderen bei Sonnenlicht oder auf schwachen Bildschirmen. Die WCAG verlangen auf Stufe AA für normalen Text ein Kontrastverhältnis von mindestens 4,5:1 und für großen Text (ab 18 Punkt oder 14 Punkt fett) von mindestens 3:1 (Erfolgskriterium 1.4.3). Für Bedienelemente und informative Grafiken gilt ebenfalls mindestens 3:1 (1.4.11) (W3C: Understanding Contrast (Minimum)). Zu geringer Textkontrast war im WebAIM Million 2026 mit 83,9 % der Startseiten der mit Abstand häufigste Fehler (WebAIM: The WebAIM Million).

So prüfen wir. Repräsentative Farbpaare – Fließtext, Links, Schaltflächen, Formularhinweise, Text auf Bildern – werden mit einer reproduzierbaren Methode gemessen und dokumentiert.

Typische Befunde.

  • Hellgrauer Text auf weißem Hintergrund, etwa bei Hinweisen oder Fußzeilen.
  • Weißer Text auf hellen Markenfarben.
  • Text auf Fotos ohne abdunkelnde Fläche.
  • Platzhaltertexte in Formularen mit zu geringem Kontrast.

Was Sie tun können. Prüfen Sie Ihre Markenfarben auf Kontrasttauglichkeit und legen Sie bei Bedarf dunklere Varianten für Text fest. Verwenden Sie für Text auf Bildern eine halbtransparente Hinterlegung.

Grenzen der Aussage. Eine Stichprobe erfasst nicht alle Farbkombinationen, Zustände wie Mausberührung oder Fokus und alle Hintergründe.

Formularbeschriftungen

Worum es geht. Untersucht wird, ob öffentliche Formularfelder eindeutige, programmatisch verknüpfte Beschriftungen und verständliche Hinweise haben. Formulare werden dabei nicht abgeschickt.

Warum das wichtig ist. Ohne verknüpfte Beschriftung hört ein Screenreader-Nutzer nur „Eingabefeld“ und weiß nicht, was er eintragen soll. Die WCAG verlangen Beschriftungen oder Anweisungen, wenn Eingaben erforderlich sind (Erfolgskriterium 3.3.2), und dass Eingabefehler erkannt und in Textform beschrieben werden (3.3.1) (W3C: Understanding Labels or Instructions, W3C WAI: Forms Tutorial – Labels). Fehlende Formularbeschriftungen fanden sich 2026 auf 51 % der von WebAIM untersuchten Startseiten (WebAIM: The WebAIM Million).

So prüfen wir. Felder ausgewählter Formulare werden auf sichtbare Beschriftung, programmatische Verknüpfung, Kennzeichnung von Pflichtfeldern und Hinweise zum erwarteten Format geprüft.

Typische Befunde.

  • Platzhaltertext als einzige Beschriftung, der beim Tippen verschwindet.
  • Pflichtfelder, die nur durch Farbe oder ein unerklärtes Sternchen gekennzeichnet sind.
  • Kontrollkästchen, etwa zur Datenschutzerklärung, ohne verknüpften Text.

Was Sie tun können. Verknüpfen Sie jedes Feld über ein label-Element mit einer dauerhaft sichtbaren Beschriftung, kennzeichnen Sie Pflichtfelder in Textform und erklären Sie erwartete Formate vor der Eingabe.

Grenzen der Aussage. Eine Prüfung ohne Absenden erfasst nicht das vollständige Verhalten bei Fehlern und Bestätigungen.

Automatisierter Accessibility-Snapshot

Worum es geht. Ein automatisches Prüfwerkzeug untersucht ausgewählte Seiten auf technisch erkennbare Barrieren. Werkzeug, Version und Seitenumfang werden dokumentiert.

Warum das wichtig ist. Automatische Scans finden wiederkehrende Muster schnell und reproduzierbar – etwa fehlende Alternativtexte, leere Links oder Kontrastfehler – und helfen, große Seitenbestände zu priorisieren. Sie können aber nur einen Teil der Anforderungen beurteilen: Ob ein Alternativtext sinnvoll ist oder eine Tastaturbedienung logisch funktioniert, erkennt kein Werkzeug zuverlässig (W3C WAI: Web Accessibility Evaluation Tools List).

So prüfen wir. Der Scan läuft auf einer definierten Auswahl von Seiten. Die Ergebnisse werden mit den manuellen Stichproben abgeglichen, damit Fehlalarme nicht als Befund ausgegeben und echte Barrieren nicht übersehen werden.

Typische Befunde.

  • Viele gleichartige Fehler aus einer gemeinsamen Seitenvorlage, die sich zentral beheben lassen.
  • Fehler in eingebundenen Drittanbieter-Elementen wie Karten, Chats oder Cookie-Bannern.
  • Hinweise, die manuell geprüft werden müssen, etwa zur Sinnhaftigkeit von Beschriftungen.

Was Sie tun können. Beheben Sie Fehler bevorzugt in Vorlagen und Komponenten, weil das auf allen Seiten gleichzeitig wirkt. Bauen Sie einen automatischen Test in Ihren Veröffentlichungsprozess ein, damit neue Fehler früh auffallen. Kostenlose Browser-Erweiterungen wie WAVE oder axe DevTools ermöglichen einen ersten eigenen Test.

Grenzen der Aussage. Ein automatisierter Scan belegt allein keine WCAG-Konformität – weder im positiven noch im negativen Sinn.

Quellen

Die Aussagen auf dieser Seite stützen sich auf die folgenden Quellen, geordnet nach Herausgeber. Angaben von Anbietern beschreiben, was ein Unternehmen über sein eigenes System sagt; sie sind dafür die maßgebliche Quelle und können sich jederzeit ändern. Bei Gesetzen, Standards und technischen Referenzen nennen wir die geltende Fassung.

W3C
Das W3C gibt mit den WCAG den internationalen Maßstab vor; die Web Accessibility Initiative erläutert einzelne Erfolgskriterien, Prüfmethoden und Werkzeuge.
WebAIM
WebAIM prüft jährlich automatisiert die Startseiten der eine Million meistbesuchten Websites.
ETSI, CEN, CENELEC
Die europäische Norm EN 301 549 übersetzt die Anforderungen in einen technischen Maßstab für Produkte und Dienstleistungen.
Bundesamt für Justiz
Das Barrierefreiheitsstärkungsgesetz regelt, welche Angebote seit dem 28. Juni 2025 barrierefrei sein müssen und welche Informationen bereitzustellen sind.
Europäische Union
Der Durchführungsbeschluss der Kommission benennt die derzeit harmonisierte Fassung der Norm für Websites öffentlicher Stellen.
Marktüberwachung Barrierefreiheit
Behörden von Bund und Ländern informieren über die zuständige Marktüberwachungsstelle (MLBF).
National Disability Authority (Irland)
Die irische Fachbehörde berichtet über die Veröffentlichung von EN 301 549 V4.1.1 und den erwarteten Zeitplan.
Federal Trade Commission (USA)
Die US-Verbraucherschutzbehörde FTC hat Werbeversprechen eines Overlay-Anbieters untersagt.

Häufige Fragen.

Gilt das BFSG auch für meine Unternehmenswebsite?

Das hängt davon ab, ob Sie über die Website Dienstleistungen im elektronischen Geschäftsverkehr für Verbraucher anbieten – etwa einen Online-Shop, eine Buchung oder einen Vertragsabschluss – und ob die Ausnahme für Kleinstunternehmen greift. Reine B2B-Angebote richten sich nicht an Verbraucher. Die Einordnung ist eine rechtliche Einzelfallfrage, die Sie rechtlich prüfen lassen sollten.

Reicht ein Barrierefreiheits-Plugin oder Overlay?

Nein. Werkzeuge, die nachträglich eine Bedienleiste über die Website legen, verändern den eigentlichen Code der Website nicht. Fehlende Beschriftungen, falsche Strukturen oder Tastaturfallen müssen in der Website selbst korrigiert werden. Wie weit Versprechen solcher Werkzeuge reichen können, zeigt ein Verfahren der US-Verbraucherschutzbehörde FTC: Sie untersagte dem Anbieter accessiBe im April 2025, ohne belastbare Nachweise zu behaupten, sein automatisiertes Produkt könne jede Website WCAG-konform machen oder dauerhaft konform halten, und verpflichtete ihn zur Zahlung von 1 Million US-Dollar (Federal Trade Commission: Final Order gegen accessiBe (04/2025)).

Bedeutet ein fehlerfreier automatischer Scan, dass meine Website barrierefrei ist?

Nein. Automatische Werkzeuge erkennen nur einen Teil der Barrieren. Auch WebAIM stellt ausdrücklich klar, dass das Fehlen erkannter Fehler keine Barrierefreiheit belegt. Eine belastbare Aussage erfordert manuelle Prüfungen, idealerweise ergänzt um Tests mit Menschen mit Behinderungen.

Welche WCAG-Version sollte ich anstreben?

Für neue Projekte und Überarbeitungen ist WCAG 2.2 auf Stufe AA das sinnvolle Ziel. Die neue europäische Norm EN 301 549 V4.1.1 baut auf WCAG 2.2 auf. Laut W3C erfüllen Inhalte, die WCAG 2.2 entsprechen, grundsätzlich auch WCAG 2.1 und 2.0 (W3C: WCAG 2.2).

Was ist eine Erklärung zur Barrierefreiheit?

Wer Dienstleistungen anbietet, die unter das BFSG fallen, muss nach § 14 BFSG Informationen darüber bereitstellen, wie die Dienstleistung die Barrierefreiheitsanforderungen erfüllt. Nach Anlage 3 geschieht das etwa in den Allgemeinen Geschäftsbedingungen oder auf andere deutlich wahrnehmbare Weise; dazu gehört unter anderem die Angabe der zuständigen Marktüberwachungsbehörde. Viele Anbieter nutzen dafür eine eigene Seite (BFSG § 14, BFSG Anlage 3). Inhalt und Umfang sollten Sie rechtlich prüfen lassen.

Weiterlesen.

Nutzerführung & ConversionErster Eindruck, Navigation, Formulare und Fehlermeldungen KI-Crawler und KI-AgentenWelche KI-Systeme Ihre Website abrufen und wie Sie das steuern MethodikStichprobe, Belege, Gewichtung und Grenzen Alle Prüfbereiche im ÜberblickÜbersicht aller Prüfbereiche und Beiträge

Wo hat Ihre Website Barrieren – bei Tastatur, Kontrast oder Formularen?

Pixelkiez prüft bis zu sechs öffentliche Seiten Ihrer Website persönlich und schickt Ihnen einen Bericht mit sieben Seiten als PDF. Kostenlos, ohne Abo.

Kostenlose Analyse-Anfragen in Kürze verfügbar.