- Sieben gezielte Prüfungen zeigen in etwa 30 Minuten, wo Ihre Website steht, ohne Vorkenntnisse.
- Automatische Werkzeuge wie Axe oder WAVE finden in Studien 57 Prozent der Barrieren, gegenüber den branchenüblich 20 bis 30 Prozent. Den Rest deckt erst der manuelle Test auf.
- Jede Prüfung ist einem konkreten WCAG-2.2-Kriterium zugeordnet, das das BFSG als Maßstab vorschreibt.
- Wo die Selbstprüfung endet und eine dokumentierte Fachprüfung beginnen muss, zeigt Prüfung sieben.
Warum diese Prüfungen sinnvoll sind
Ob Ihre Website zugänglich ist, finden Sie mit sieben gezielten Prüfungen in etwa 30 Minuten heraus, ohne Vorkenntnisse in der Webentwicklung. Seit dem Barrierefreiheitsstärkungsgesetz (BFSG) müssen sich auch viele Unternehmen mit dem Thema befassen, nicht mehr nur öffentliche Stellen. Die Frist lief am 28. Juni 2025 ab. Wer jetzt wissen will, wo die eigene Seite steht, braucht keine teure Fachprüfung als ersten Schritt, sondern eine strukturierte Selbstkontrolle.
Diese sieben Prüfungen decken die häufigsten und schwerwiegendsten Barrieren ab. Jede ist einem konkreten WCAG-2.2-Kriterium zugeordnet. Was WCAG 2.2 in der Tiefe bedeutet, erklärt der Artikel WCAG 2.2 Stufe AA verständlich erklärt. Hier geht es ums Tun.
Was WCAG 2.2 verlangt und was das bedeutet
Die Web Content Accessibility Guidelines (WCAG) des W3C gliedern sich in vier Prinzipien: wahrnehmbar, bedienbar, verständlich, robust. Dahinter stecken über 50 Erfolgskriterien auf den Stufen A und AA. Die sieben Prüfungen in diesem Artikel konzentrieren sich auf die Kriterien, die in der Praxis am häufigsten verletzt werden und die gravierendsten Nutzerprobleme verursachen.
Die 7 Prüfungen im Detail
Prüfung 1: Automatischer Scan mit Axe oder WAVE
Typische Treffer: fehlende Alternativtexte, zu schwache Kontraste, fehlende Formular-Beschriftungen. Wie weit automatische Werkzeuge wirklich tragen, hat Deque in einer eigenen Studie zur automatischen Testabdeckung untersucht: Je nach Seitentyp und Prüfmethode fanden die Werkzeuge 57 Prozent aller Barrieren, deutlich mehr als die branchenweit üblichen 20 bis 30 Prozent. Die Spanne erklärt sich dadurch, dass einfache Fehler wie fehlende Alt-Attribute zuverlässig erkannt werden, während Interaktionsprobleme und Kontextfehler grundsätzlich außen vor bleiben. Den Rest findet man nur manuell. Was das Werkzeug aber meldet, stimmt fast immer: falsch-positive Ergebnisse sind bei Axe die Ausnahme.
Alternativ können Sie den Accessibility-Tab in den Chromium-Entwicklertools nutzen oder Lighthouse aus demselben DevTools-Fenster starten. Lighthouse gibt zusätzlich Hinweise zu Performance und SEO, die Barrierefreiheitsprüfung ist ein Teilaspekt davon.
Zugehöriges WCAG-Prinzip: alle vier Grundprinzipien, automatisch auswertbar.
Prüfung 2: Tastaturbedienung ohne Maus
Diese Prüfung ist der wichtigste manuelle Einzeltest, und gleichzeitig derjenige, der Kunden am häufigsten überrascht. Wer bisher nicht mit der Tab-Taste durch seine eigene Website navigiert hat, entdeckt dabei fast immer etwas.
Menschen, die keine Maus nutzen können, sind komplett ausgesperrt, wenn dieser Test scheitert. Dazu zählen nicht nur Rollstuhlfahrer, sondern auch Menschen mit Zittern, temporären Verletzungen oder sprachgesteuerter Eingabe. WCAG 2.2 Kriterium 2.1.1 Tastatur (Stufe A) verlangt, dass alle Funktionen per Tastatur auslösbar sind, ohne Ausnahme.
Häufigster Fehler: ein anklickbares div oder span statt eines echten <button>-Elements. Ein div ist von Haus aus nicht per Tab erreichbar. Für eine vertiefte Anleitung zum Tastaturtest schauen Sie sich Tastaturbedienung testen an.
Prüfung 3: Fokus sichtbar
Der Fokusindikator ist das visuelle Gegenstück zur Tastaturbedienung. Wer durch die Seite tabbt und nicht sieht, wo er gerade ist, kann genauso wenig navigieren wie jemand, der die Tastatur gar nicht benutzen kann.
WCAG 2.2 Kriterium 2.4.7 Fokus sichtbar (Stufe AA) fordert einen erkennbaren Fokusindikator für alle interaktiven Elemente. Neu in WCAG 2.2: Kriterium 2.4.11 Fokus-Erscheinungsbild (Stufe AA) legt zusätzliche Mindestanforderungen fest. Der Fokusring muss einen definierten Mindestbereich umfassen und einen Kontrast von 3:1 zur angrenzenden Farbe aufweisen.
Die häufigste Ursache ist ein CSS-Reset: outline: none oder outline: 0, das viele Themes aus optischen Gründen setzen. Lässt sich schnell prüfen: Öffnen Sie die Entwicklertools, wählen Sie ein interaktives Element und suchen Sie im Styles-Panel nach outline.
Prüfung 4: Farbkontraste
WCAG 2.2 Kriterium 1.4.3 Kontrast (Minimum) (Stufe AA) fordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text. Für Schrift ab 18 Punkt oder ab 14 Punkt fett genügen 3:1. Dekorative Texte und inaktive Bedienelemente sind ausgenommen.
Typische Problemstellen: blasse Grautöne auf Weiß, helle Farben auf hellem Hintergrund, Text über Hintergrundfotos. Kontrastfehler gehören zu den teuersten Korrekturen, wenn das Farbsystem einer Website grundsätzlich nicht darauf ausgelegt wurde. Eine ausführliche Anleitung zum Kontrast-Audit inklusive Dokumentation finden Sie in Farbkontrast nach WCAG richtig prüfen.
Prüfung 5: Alternativtexte der Bilder
<img-Elementen. Jedes inhaltstragende Bild braucht ein alt-Attribut, das beschreibt, was auf dem Bild zu sehen ist. Dekorative Bilder bekommen ein leeres alt="". Fehlt das Attribut ganz oder steht dort ein Dateiname wie bild_final_v2.jpg, ist das ein Fehler.WCAG 2.2 Kriterium 1.1.1 Nicht-Text-Inhalte (Stufe A) ist das am häufigsten verletzte einzelne Kriterium auf deutschen Unternehmenswebsites. Ein fehlender Alternativtext bedeutet, dass ein Screenreader nur den Dateinamen vorliest oder das Bild ganz überspringt. Bei Produktfotos im Shop, erklärenden Diagrammen oder Grafiken mit Textinhalt ist das ein echter Informationsverlust.
Axe findet fehlende Alt-Attribute zuverlässig. Was es nicht prüfen kann: ob ein vorhandener Alt-Text sinnvoll ist. „Bild 1“ ist technisch vorhanden und trotzdem wertlos.
Prüfung 6: Formularlabels und Eingabefelder
Kontaktformulare und Checkouts sind die neuralgischen Punkte. Wer diese Prüfung überspringt, riskiert, dass Menschen mit Screenreader ausgerechnet dort scheitern, wo eine Handlung abgeschlossen werden soll.
WCAG 2.2 Kriterium 3.3.2 Beschriftungen oder Anweisungen (Stufe AA) verlangt sichtbare, dauerhaft vorhandene Beschriftungen. Ein placeholder-Attribut allein genügt nicht: Es verschwindet beim Tippen und wird von manchen Hilfsmitteln gar nicht vorgelesen. Die korrekte Umsetzung ist ein <label for="feld-id">, das programmatisch mit dem Feld verbunden ist.
Fehler bei Formularfeldern führen dazu, dass Menschen mit Screenreader nicht wissen, was sie in ein Feld eingeben sollen. Das ist einer der häufigsten Gründe, warum Nutzer mit Einschränkungen Formulare und Checkouts abbrechen. Wie ein zugängliches Formular technisch aussieht, erklärt Barrierefreie Formulare: Schritt für Schritt.
Prüfung 7a: Überschriftenstruktur
Die Überschriftenstruktur fällt unter WCAG 2.2 Kriterium 1.3.1 Informationen und Beziehungen (Stufe A). Screenreader-Nutzer navigieren Seiten hauptsächlich über Überschriften, ähnlich wie ein Sehender über das visuelle Layout scannt. Ein Sprung in der Hierarchie oder mehrere H1 auf einer Seite zerstören diese Navigation vollständig.
Prüfung 7b: Text-Zoom und Tap-Ziele
Der Zoom-Test gehört zu WCAG 2.2 Kriterium 1.4.4 Textgröße ändern (Stufe AA): Text muss sich auf 200 Prozent vergrößern lassen, ohne dass Inhalt oder Funktionalität verloren geht. Viele ältere Themes sperren den Zoom mit einem Meta-Viewport-Tag wie user-scalable=no. Das ist ein direkter Verstoß.
Neu in WCAG 2.2 ist Kriterium 2.5.8 Zielgröße (Minimum) (Stufe AA): Bedienelemente auf Touchscreens müssen mindestens 24 x 24 CSS-Pixel groß sein oder ausreichend Abstand zu benachbarten Elementen aufweisen. Damit wird das bekannte Problem zu kleiner Tap-Targets auf Mobilgeräten erstmals normativ verankert. Wer einen WCAG-2.2-konformen Stand nachweisen will, muss dieses Kriterium mitprüfen.
Übersicht: Alle 7 Prüfungen auf einen Blick
| Prüfung | Werkzeug | WCAG-Kriterium | Stufe |
|---|---|---|---|
| 1. Automatischer Scan | Axe DevTools, WAVE, Lighthouse | Mehrere, automatisch auswertbar | A + AA |
| 2. Tastaturbedienung | Manuell mit Tab-Taste | 2.1.1 Tastatur | A |
| 3. Fokus sichtbar | Manuell, ergänzend Axe | 2.4.7 Fokus sichtbar, 2.4.11 Fokus-Erscheinungsbild | AA |
| 4. Farbkontraste | WAVE, WebAIM Contrast Checker | 1.4.3 Kontrast (Minimum) | AA |
| 5. Alternativtexte | Axe DevTools, F12 Entwicklertools | 1.1.1 Nicht-Text-Inhalte | A |
| 6. Formularlabels | Manuell + Axe | 3.3.2 Beschriftungen | AA |
| 7a. Überschriftenstruktur | Headings Map Erweiterung | 1.3.1 Informationen und Beziehungen | A |
| 7b. Zoom + Tap-Ziele | Browser-Zoom 200 %, Mobilgerät | 1.4.4 Textgröße ändern, 2.5.8 Zielgröße (Minimum) | AA |
Was automatische Tools nicht finden
Automatische Werkzeuge sind eine unverzichtbare erste Stufe, aber sie liefern keinen vollständigen Befund. Was sie zuverlässig finden: fehlende Alt-Attribute, zu schwache Kontraste, fehlende Formular-Labels, leere Links. Was sie nicht finden:
- Ob ein Alternativtext sinnvoll ist (technisch vorhanden, inhaltlich wertlos)
- Ob ein interaktives Element per Tastatur erreichbar ist (ein fehlendes
tabindexauf einemdiv) - Ob die Reihenfolge im DOM der visuellen Reihenfolge entspricht
- Ob eine Fehlermeldung verständlich ist
- Ob ein Modal-Dialog den Fokus korrekt fängt und zurückgibt
Wer eine dokumentierte Konformitätsbewertung braucht, die vor Behörden standhält, kommt an einer manuellen Prüfung mit einem echten Screenreader nicht vorbei. Das ist kein optionaler Schritt, sondern Voraussetzung für eine belastbare Barrierefreiheitserklärung. Kostenlose Screenreader für den Einstieg: NVDA für Windows (kostenlos) und VoiceOver, das in macOS und iOS bereits eingebaut ist.
Praxisbeispiel: Was eine 30-Minuten-Prüfung aufdeckt
Das folgende Muster begegnet uns regelmäßig bei Mittelstandskunden, die ihre Website kurz zuvor neu oder überarbeitet haben. Axe meldet zwei bis vier kritische Fehler, überwiegend fehlende Alt-Attribute auf Teamfotos und einen Kontrastfehler auf der Preisseite. Diese Punkte sind in einer Stunde behoben. Beim anschließenden manuellen Tastaturtest zeigt sich dann das eigentliche Problem: Das Hauptmenü lässt sich per Tastatur nicht aufklappen. Der Fehler liegt in einem Theme-eigenen JavaScript, das nur Klick-Events registriert, aber keine Tastaturevents. Kein automatisches Werkzeug hätte das gefunden.
Was dieses Muster besonders prägt: Die Websites hatten kurz zuvor ein Redesign hinter sich. Das neue Theme sah besser aus, hatte aber weniger Barrierefreiheit als das alte. Der Tastaturtest kostet 15 Minuten und hätte diesen Fehler im Review vor dem Launch gefunden. Deshalb gehört er in jeden Abnahmeprozess.
Eine systematische Liste der häufigsten Fehler auf Mittelstands-Websites findet sich im Artikel Die 12 häufigsten Barrierefreiheitsfehler.
Schnellcheck: Wo steht Ihre Website heute?
Bevor Sie die sieben Prüfungen durchgehen, gibt der kostenlose Selbsttest eine erste Einordnung: Ist Ihr Unternehmen überhaupt vom BFSG betroffen, und wie groß ist das Risiko bei Ihrem aktuellen Stand?
Wann reicht die Selbstprüfung, wann braucht es Fachleute?
Für eine erste Einschätzung und die Behebung offensichtlicher Fehler reicht die Selbstprüfung. Sobald es um eine dokumentierte Konformitätsbewertung, eine Barrierefreiheitserklärung oder rechtliche Absicherung geht, braucht es eine fachlich durchgeführte Prüfung.
Das gilt auch, wenn die Prüfung viele Mängel zeigt und unklar bleibt, wie sie zu priorisieren und konkret zu beheben sind. Eine strukturierte Prüfung liefert dann nicht nur eine Fehlerliste, sondern einen umsetzbaren Maßnahmenplan mit klarer Reihenfolge. Wenn Sie wissen möchten, wo Ihre Website genau steht, fasst der Website-Check von ihp media die Barrierefreiheit zusammen mit Technik, Performance und SEO in einer übersichtlichen Auswertung aus einer Hand.
Sofort-Checkliste: 7 Prüfungen
- Automatischen Scan mit Axe oder WAVE durchgeführt, alle roten Fehler notiert?
- Startseite nur mit der Tastatur komplett navigierbar (Tab, Enter, Shift+Tab)?
- Fokusmarkierung bei jedem interaktiven Element sichtbar, auch nach Tab in Menüs?
- Kontraste aller Texte und Beschriftungen mindestens 4,5:1 (große Schrift: 3:1)?
- Alle inhaltstragenden Bilder mit sinnvollem Alt-Text, dekorative mit
alt=""? - Jedes Formularfeld hat ein sichtbares, verknüpftes Label (kein bloßer Platzhalter)?
- Überschriftenhierarchie lückenlos (eine H1, H2 vor H3)?
- Browser-Zoom 200 % ohne Inhaltsverlust, Tap-Ziele auf Mobilgeräten ausreichend groß?
- Drei der sieben Prüfungen sind manuell: Tastatur, Fokus und Formularlabels findet kein automatisches Werkzeug vollständig.
- Automatische Tools (Axe, WAVE, Lighthouse) sind unverzichtbar, liefern aber nur einen Teilbefund: in der Deque-Studie 57 Prozent der Barrieren, branchenüblich bislang 20 bis 30 Prozent.
- Jede Prüfung ist einem WCAG-2.2-Kriterium zugeordnet, das das BFSG als Pflicht vorschreibt.
- Wer eine Barrierefreiheitserklärung veröffentlichen will, die standhält, kommt an einer Prüfung mit echtem Screenreader nicht vorbei.
Häufige Fragen
Reicht der Axe-Scan, um zu wissen, ob meine Website barrierefrei ist?
Nein. Axe findet automatisch auswertbare Fehler zuverlässig, aber Studien zeigen, dass automatische Werkzeuge in der Deque-Studie 57 Prozent der WCAG-Verstöße aufdecken, gegenüber den branchenüblich 20 bis 30 Prozent. Den Rest, vor allem Probleme bei der Tastaturbedienung, beim Fokus-Management und bei Formularlabels, findet man nur durch manuelles Testen.
Wie lange dauert eine professionelle Barrierefreiheitsprüfung?
Das hängt vom Umfang der Website ab. Eine fundierte manuelle Prüfung einer mittelgroßen Seite mit 10 bis 20 relevanten Seitentypen dauert in der Regel mehrere Stunden bis zu einem Tag. Das Ergebnis ist eine dokumentierte Liste der Mängel, jeweils mit dem betroffenen WCAG-Kriterium, dem Schweregrad und einer Handlungsempfehlung.
Welche WCAG-Version muss ich einhalten?
Das BFSG verweist auf die harmonisierte europäische Norm EN 301 549. Deren aktuelle Fassung 3.2.1 referenziert WCAG 2.1 Stufe AA als Mindestanforderung. Eine Aktualisierung auf WCAG 2.2 ist in Arbeit, steht offiziell aber noch nicht fest. Wer jetzt nach WCAG 2.2 Stufe AA baut, erfüllt das ältere Minimum automatisch mit und ist für künftige Anpassungen der Norm gerüstet.
Was kostet es, Barrierefreiheitsfehler zu beheben?
Das ist sehr unterschiedlich. Fehlende Alternativtexte und eine falsche Überschriftenstruktur lassen sich oft in wenigen Stunden korrigieren. Grundlegende Probleme bei der Tastaturbedienung oder im Farbsystem können aufwendiger sein und mehr Entwicklungszeit kosten. Deshalb lohnt sich die Priorisierung nach Schweregrad, damit das Budget zuerst in die wirksamsten Korrekturen fließt.
Gilt das BFSG wirklich für mein kleines Unternehmen?
In den meisten Fällen ja. Von der Pflicht befreit sind nur Kleinstunternehmen, die weniger als zehn Beschäftigte haben und zugleich höchstens zwei Millionen Euro Jahresumsatz oder Jahresbilanzsumme erreichen, und auch das nur für Dienstleistungen. Für Onlineshops mit Warenverkauf gilt die Ausnahme nicht. Mehr dazu im Artikel BFSG und Onlineshop.
Gibt es ein offizielles Zertifikat für barrierefreie Websites?
Ein staatliches Zertifikat gibt es nicht. Das anerkannte Dokument ist eine Barrierefreiheitserklärung, die beschreibt, in welchem Umfang die Website die Anforderungen erfüllt und auf welcher Grundlage das geprüft wurde. Sie gehört auf die Website und sollte bei wesentlichen Änderungen aktualisiert werden. Was genau hineingehört, zeigt der Artikel Barrierefreiheitserklärung erstellen.