Leistungsumfang BFSG: alle 39 WCAG-AA-Prüfpunkte
Transparente Übersicht aller Prüfungen – was wird geprüft, welche Rechtsgrundlage steckt dahinter und was ist in welchem Produkt enthalten.
Geprüft wird gegen WCAG 2.1 Level AA – den Standard, auf den EN 301 549 verweist und den das BFSG über § 3 in Bezug nimmt.
Zwei Prüfungen greifen bereits WCAG 2.2 vor: die Zielgröße von Klick- und Touchflächen (2.5.8) und Alternativen zu Ziehbewegungen (2.5.7). Sie sind im Katalog als solche gekennzeichnet und gehen über die 2.1-Anforderung hinaus.
Wahrnehmbar (Perceivable)
Worum geht es?
Informationen und Bestandteile der Benutzeroberfläche müssen so präsentiert werden, dass sie von allen Nutzern wahrgenommen werden können — unabhängig von Seh-, Hör- oder kognitiven Einschränkungen.
Rechtliche Grundlage
WCAG 2.1 — Prinzip 1 (Richtlinien 1.1 bis 1.4). Seit 28.06.2025 gesetzliche Pflicht nach § 3 BFSG i.V.m. EN 301 549. Verstöße können Unterlassungsklagen und Bußgelder bis 100.000 € nach sich ziehen.
Praxis-Tipp
Beginnen Sie mit Alt-Texten für alle Bilder, prüfen Sie Farbkontraste (mind. 4.5:1) und stellen Sie sicher, dass Ihre Seite bei 200% Zoom noch nutzbar ist. Tools: WebAIM Contrast Checker, axe DevTools.
| ID | Prüfung | Schwere | WCAG-Referenz |
|---|---|---|---|
| P-01 |
Alt-Texte für Bilder
Jedes informative Bild muss einen beschreibenden Alt-Text haben. Dekorative Bilder erhalten alt="" (leer). Screenreader lesen den Alt-Text vor — fehlt er, wird der Dateiname vorgelesen, was für blinde Nutzer unverständlich ist.
|
HOCH | WCAG 1.1.1 (A) |
| P-02 |
Video-Untertitel
Voraufgezeichnete Videos müssen synchrone Untertitel haben. Dies betrifft auch in Webseiten eingebettete YouTube- oder Vimeo-Videos. Automatisch generierte Untertitel gelten nur als Notlösung.
|
HOCH | WCAG 1.2.2 (A) |
| P-03 |
Audiodeskription für Videos
Videos müssen eine Audiodeskription bieten, die visuelle Informationen beschreibt, die nicht aus dem Audiotrack hervorgehen (z.B. eingeblendete Texte, Handlungen ohne Dialog).
|
MITTEL | WCAG 1.2.5 (AA) |
| P-04 |
Semantische Struktur
Informationen, Struktur und Beziehungen müssen programmatisch bestimmbar sein: korrekte Heading-Hierarchie (h1→h6), Listen als <ul>/<ol>, Tabellen mit <th>-Headern. Screenreader navigieren anhand dieser Struktur.
|
HOCH | WCAG 1.3.1 (A) |
| P-05 |
Sinnvolle Reihenfolge
Die Lesereihenfolge im DOM muss der visuellen Reihenfolge entsprechen. CSS-basierte visuelle Umordnung (z.B. flexbox order, grid) kann dazu führen, dass Screenreader Inhalte in falscher Reihenfolge vorlesen.
|
MITTEL | WCAG 1.3.2 (A) |
| P-06 |
Sensorische Merkmale
Anweisungen dürfen nicht ausschließlich auf sensorischen Merkmalen basieren (z.B. "Klicken Sie auf den roten Button", "das Feld rechts"). Stattdessen zusätzlich den Namen oder die Funktion nennen.
|
MITTEL | WCAG 1.3.3 (A) |
| P-07 |
Eingabezweck erkennbar
Eingabefelder für personenbezogene Daten (Name, Adresse, E-Mail) müssen das autocomplete-Attribut korrekt verwenden. Dies ermöglicht Autofill und hilft Menschen mit motorischen oder kognitiven Einschränkungen.
|
MITTEL | WCAG 1.3.5 (AA) |
| P-08 |
Farbe nicht einziges Unterscheidungsmerkmal
Informationen dürfen nicht ausschließlich durch Farbe vermittelt werden. Fehlerfelder nicht nur rot markieren, sondern zusätzlich mit Icon oder Text. Pflichtfelder nicht nur mit Sternchen in roter Farbe.
|
HOCH | WCAG 1.4.1 (A) |
| P-09 |
Farbkontrast (4.5:1)
Text muss ein Kontrastverhältnis von mindestens 4.5:1 zum Hintergrund haben (normaler Text) bzw. 3:1 (großer Text ≥ 18px oder fett ≥ 14px). Geprüft werden alle sichtbaren Textelemente nach CSS-Rendering.
|
HOCH | WCAG 1.4.3 (AA) |
| P-10 |
Textgröße änderbar (200%)
Text muss bis 200% vergrößert werden können, ohne dass Inhalt oder Funktionalität verloren gehen. Feste Pixel-Höhen bei Containern mit overflow:hidden sind eine häufige Ursache für Verstöße.
|
HOCH | WCAG 1.4.4 (AA) |
| P-11 |
Kein Text als Bild
Text soll nicht als Bild dargestellt werden, es sei denn, es handelt sich um Logos oder rein dekorative Elemente. Bildtext lässt sich nicht skalieren, kann nicht von Screenreadern gelesen und nicht per Textsuche gefunden werden.
|
MITTEL | WCAG 1.4.5 (AA) |
| P-12 |
Reflow (kein horizontales Scrollen bei 320px)
Inhalte müssen bei 320px Breite ohne horizontales Scrollen darstellbar sein. Dies entspricht 400% Zoom auf einem 1280px-Monitor. Ausnahmen: Datentabellen, Bilder, Karten, Videos.
|
HOCH | WCAG 1.4.10 (AA) |
| P-13 |
Nicht-Text-Kontrast (3:1)
UI-Komponenten (Buttons, Formularfelder, Icons) und grafische Objekte müssen ein Kontrastverhältnis von mindestens 3:1 zum Hintergrund haben. Betrifft auch Fokus-Indikatoren und Rahmen.
|
MITTEL | WCAG 1.4.11 (AA) |
| P-14 |
Textabstand anpassbar
Nutzer müssen Textabstände (Zeilenabstand, Absatzabstand, Buchstabenabstand, Wortabstand) erhöhen können, ohne dass Inhalte abgeschnitten werden oder die Funktionalität verloren geht.
|
MITTEL | WCAG 1.4.12 (AA) |
Bedienbar (Operable)
Worum geht es?
Alle Funktionen müssen per Tastatur bedienbar sein. Navigation muss vorhersagbar sein, und Nutzer müssen ausreichend Zeit für Interaktionen haben.
Rechtliche Grundlage
WCAG 2.1 — Prinzip 2 (Richtlinien 2.1 bis 2.5). Tastaturzugänglichkeit ist die Grundvoraussetzung für Barrierefreiheit — ohne sie können motorisch eingeschränkte Nutzer die Website nicht bedienen.
Praxis-Tipp
Testen Sie Ihre Website ausschließlich mit der Tastatur (Tab, Enter, Escape, Pfeiltasten). Wenn Sie irgendwo nicht weiterkommen oder den Fokus nicht sehen können, haben andere Nutzer dasselbe Problem.
| ID | Prüfung | Schwere | WCAG-Referenz |
|---|---|---|---|
| O-01 |
Tastaturzugang
Alle Funktionen müssen über die Tastatur erreichbar und bedienbar sein. Dazu gehören: Navigation, Links, Buttons, Formulare, Dropdowns, Modals, Slider und alle interaktiven Elemente.
|
KRITISCH | WCAG 2.1.1 (A) |
| O-02 |
Keine Tastaturfalle
Der Fokus darf nie in einem Element gefangen sein, aus dem man per Tastatur nicht mehr herauskommt. Häufige Fallen: Modals ohne Escape-Handling, eingebettete Widgets, iframes ohne Tab-Austritt.
|
KRITISCH | WCAG 2.1.2 (A) |
| O-03 |
Skip-Link vorhanden
Am Seitenanfang muss ein Mechanismus vorhanden sein, um wiederkehrende Inhaltsblöcke (Navigation, Header) zu überspringen. Typisch: "Zum Inhalt springen" als erstes fokussierbares Element.
|
HOCH | WCAG 2.4.1 (A) |
| O-04 |
Seitentitel vorhanden
Jede Seite muss einen aussagekräftigen <title> haben, der Zweck und Kontext beschreibt. Screenreader lesen den Titel als erstes vor. Fehlt er, können Nutzer mit vielen Tabs nicht orientieren.
|
HOCH | WCAG 2.4.2 (A) |
| O-05 |
Fokus-Reihenfolge logisch
Die Tab-Reihenfolge muss der logischen Lesereihenfolge entsprechen. Positive tabindex-Werte (>0) ändern die natürliche Reihenfolge und führen fast immer zu Problemen. Verwenden Sie ausschließlich tabindex="0" oder tabindex="-1".
|
HOCH | WCAG 2.4.3 (A) |
| O-06 |
Link-Zweck erkennbar
Der Zweck jedes Links muss aus dem Linktext oder dem Kontext erkennbar sein. "Hier klicken", "Mehr erfahren", "Weiterlesen" ohne Kontext sind nicht ausreichend.
|
MITTEL | WCAG 2.4.4 (A) |
| O-07 |
Überschriftenhierarchie
Überschriften müssen Inhalt und Abschnitte beschreiben. Die Hierarchie darf keine Ebenen überspringen (z.B. h1 direkt gefolgt von h3). Es sollte genau eine h1 pro Seite geben.
|
HOCH | WCAG 2.4.6 (AA) |
| O-08 |
Fokus sichtbar
Der Tastaturfokus muss visuell erkennbar sein. Browser-Defaults (blaue Outline) dürfen nicht per CSS entfernt werden (outline:none), ohne einen gleichwertigen Ersatz zu bieten. Mindestkontrast 3:1.
|
HOCH | WCAG 2.4.7 (AA) |
| O-09 |
Zeiger-Gesten Alternativen
Funktionalität, die mit Mehrpunkt- oder pfadbasierten Gesten bedienbar ist (z.B. Pinch-to-Zoom, Wischgesten), muss auch mit einfachen Zeigergesten (Klick, Doppelklick, Halten) bedienbar sein.
|
MITTEL | WCAG 2.5.1 (A) |
| O-10 |
Zielgröße von Klick- und Touchflächen
Klick- und Touchflächen müssen mindestens 24×24 CSS-Pixel groß sein (empfohlen: 44×44). Kleine Ziele sind für motorisch eingeschränkte Nutzer und auf mobilen Geräten schwer zu treffen.
|
MITTEL | WCAG 2.5.8 (AA, aus WCAG 2.2) |
Verständlich (Understandable)
Worum geht es?
Inhalte und Bedienung müssen verständlich sein. Die Sprache der Seite muss deklariert sein, Navigation muss konsistent und vorhersagbar sein, und Fehler müssen klar kommuniziert werden.
Rechtliche Grundlage
WCAG 2.1 — Prinzip 3 (Richtlinien 3.1 bis 3.3). Besonders relevant für E-Commerce: Fehlervermeidung bei Rechtsgeschäften ist nach WCAG 3.3.4 (AA) Pflicht.
Praxis-Tipp
Setzen Sie lang="de" auf dem HTML-Element. Zeigen Sie Fehler in Formularen direkt am betroffenen Feld an, nicht nur als allgemeine Meldung. Bieten Sie bei Bestellungen eine Überprüfungsseite vor dem endgültigen Absenden.
| ID | Prüfung | Schwere | WCAG-Referenz |
|---|---|---|---|
| U-01 |
Sprache der Seite deklariert
Das lang-Attribut auf dem <html>-Element (z.B. lang="de") ist Grundvoraussetzung für korrekte Screenreader-Aussprache, Silbentrennung und Sprachsynthese. Fehlt es, rät der Screenreader die Sprache.
|
HOCH | WCAG 3.1.1 (A) |
| U-02 |
Sprache von Textpassagen
Fremdsprachige Passagen innerhalb einer deutschsprachigen Seite müssen mit dem lang-Attribut markiert werden (z.B. <span lang="en">Terms of Service</span>), damit Screenreader die Aussprache wechseln.
|
MITTEL | WCAG 3.1.2 (AA) |
| U-03 |
Konsistente Navigation
Navigationsblöcke, die auf mehreren Seiten wiederholt werden, müssen in der gleichen Reihenfolge erscheinen. Geänderte Reihenfolge irritiert Nutzer, die sich auf gelernte Muster verlassen.
|
MITTEL | WCAG 3.2.3 (AA) |
| U-04 |
Konsistente Benennung
Elemente mit gleicher Funktion müssen konsistent benannt werden. Wenn "Suche" auf einer Seite "Suchen" und auf einer anderen "Finden" heißt, ist das verwirrend.
|
MITTEL | WCAG 3.2.4 (AA) |
| U-05 |
Fehlererkennung
Wird ein Eingabefehler erkannt, muss der Fehler in Textform beschrieben und dem Nutzer präsentiert werden. Rote Rahmen allein reichen nicht — Screenreader-Nutzer brauchen eine textuelle Beschreibung.
|
HOCH | WCAG 3.3.1 (A) |
| U-06 |
Labels und Anweisungen
Jedes Eingabefeld muss ein sichtbares Label haben, das den erwarteten Inhalt beschreibt. Placeholder-Text allein ist kein Ersatz für Labels, da er beim Tippen verschwindet.
|
HOCH | WCAG 3.3.2 (A) |
| U-07 |
Fehlervorschläge
Wenn möglich, sollen bei erkannten Fehlern konkrete Korrekturvorschläge gemacht werden. Beispiel: "Bitte geben Sie eine gültige E-Mail-Adresse ein (z.B. name@beispiel.de)".
|
MITTEL | WCAG 3.3.3 (AA) |
| U-08 |
Fehlervermeidung (Rechtsgeschäfte)
Bei Seiten, die rechtliche Verpflichtungen auslösen (Bestellungen, Verträge), muss mindestens eine Prüfmöglichkeit vor dem Absenden, eine Korrekturmöglichkeit oder eine Widerrufsmöglichkeit bestehen.
|
HOCH | WCAG 3.3.4 (AA) |
Robust
Worum geht es?
Inhalte müssen robust genug sein, um von verschiedenen Benutzeragenten (Browser, Screenreader, Braillezeile) zuverlässig interpretiert zu werden. Dazu gehören valides HTML und korrekte ARIA-Attribute.
Rechtliche Grundlage
WCAG 2.1 — Prinzip 4 (Richtlinie 4.1). Fehlerhafte ARIA-Attribute können die Zugänglichkeit verschlechtern, statt sie zu verbessern — sie überschreiben die native HTML-Semantik.
Praxis-Tipp
Nutzen Sie native HTML-Elemente (<button>, <input>, <select>) bevor Sie ARIA einsetzen. Validieren Sie Ihr HTML mit dem W3C Validator. Testen Sie mit einem Screenreader (NVDA ist kostenlos).
| ID | Prüfung | Schwere | WCAG-Referenz |
|---|---|---|---|
| R-01 |
Valides HTML (Parsing)
HTML muss syntaktisch korrekt sein: eindeutige IDs, korrekt geschachtelte Elemente, vollständige Start- und End-Tags. Fehler können dazu führen, dass Screenreader Inhalte nicht korrekt interpretieren.
|
MITTEL | WCAG 4.1.1 (A) |
| R-02 |
Name, Rolle, Wert (ARIA)
Benutzerdefinierte UI-Elemente müssen Name, Rolle und Wert programmatisch bereitstellen. Ein <div> als Button braucht role="button", aria-label und Tastatur-Handling. Besser: natives <button> verwenden.
|
HOCH | WCAG 4.1.2 (A) |
| R-03 |
Statusmeldungen programmatisch
Statusmeldungen (Erfolg, Fehler, Ladezustand) müssen per aria-live oder role="status"/"alert" für Screenreader zugänglich sein, ohne dass der Fokus verschoben wird.
|
MITTEL | WCAG 4.1.3 (AA) |
BFSG-spezifisch
Worum geht es?
Zusätzlich zu den WCAG-Anforderungen stellt das BFSG eigene organisatorische Pflichten: eine Barrierefreiheitserklärung, einen Rückmeldungsmechanismus und die Einhaltung der Umsetzungsfrist.
Rechtliche Grundlage
BFSG § 3, § 4 i.V.m. EN 301 549. Das BFSG gilt seit 28.06.2025 für B2C-Dienstleistungen im elektronischen Geschäftsverkehr. Aufsichtsbehörde ist die Marktüberwachung der Bundesländer.
Praxis-Tipp
Erstellen Sie eine Barrierefreiheitserklärung nach dem Muster der öffentlichen Hand (BIT inklusiv). Richten Sie einen Feedback-Mechanismus ein (E-Mail oder Formular), der von der Barrierefreiheitsseite verlinkt wird.
| ID | Prüfung | Schwere | WCAG-Referenz |
|---|---|---|---|
| B-01 |
Barrierefreiheitserklärung vorhanden
Eine Erklärung zur Barrierefreiheit muss öffentlich zugänglich sein. Sie muss den aktuellen Stand der Konformität beschreiben, bekannte Einschränkungen benennen und Kontaktmöglichkeiten für Barrierefreiheitsprobleme enthalten.
|
KRITISCH | § 4 BFSG |
| B-02 |
Feedback-Mechanismus
Nutzer müssen eine einfache Möglichkeit haben, Barrierefreiheitsprobleme zu melden. Dies kann ein Kontaktformular, eine E-Mail-Adresse oder ein spezieller Feedback-Button sein, der von der Barrierefreiheitserklärung verlinkt wird.
|
HOCH | § 4 BFSG |
| B-03 |
Kontaktmöglichkeit für BF-Probleme
Die Kontaktmöglichkeit muss barrierefrei nutzbar sein und in angemessener Zeit bearbeitet werden. Eine rein visuelle CAPTCHA-geschützte Kontaktseite ist selbst eine Barriere.
|
HOCH | § 4 BFSG |
| B-04 |
BFSG-Frist eingehalten (28.06.2025)
Seit dem 28.06.2025 müssen betroffene Produkte und Dienstleistungen die Anforderungen erfüllen. Ausnahmen gelten nur für Kleinstunternehmen (<10 Mitarbeiter und <2 Mio. € Umsatz) bei Dienstleistungen.
|
KRITISCH | § 4 BFSG |
39 BFSG/WCAG-Prüfungen auf Ihrer Website ausführen
Ab 29 € – oder im Bundle mit Pro-Check für 69 €.
BFSG-Check starten →