- 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. Verbindlich ist über die Norm EN 301 549 aktuell WCAG 2.1 AA, wer nach 2.2 prüft, erfüllt das ältere Minimum mit.
- 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 für kein automatisches Werkzeug erkennbar sind. Den Rest findet man nur manuell.
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 Rollstuhlfahrer ebenso wie 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 ist außerdem Kriterium 2.4.13 Fokus-Darstellung (Stufe AAA): Der Fokusindikator muss eine Mindestgröße haben und mindestens 3:1 Kontrast zur angrenzenden Farbe aufweisen. Als AAA-Kriterium liegt es über der AA-Pflicht, ist aber ein guter Maßstab für ein sauberes Fokus-Design.
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. Rein dekorative Bilder bekommen ein leeres alt="", damit Screenreader sie überspringen. Bei einem inhaltstragenden Bild ist es ein Fehler, wenn das Attribut ganz fehlt oder nur einen Dateinamen wie bild_final_v2.jpg enthält.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.13 Fokus-Darstellung | AA / AAA |
| 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
divmit Klick-Handler ist kein echtes Bedienelement und bleibt ohne Rolle und Tastaturbedienung unzugänglich) - 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 eine Handvoll kritischer Fehler, überwiegend fehlende Alt-Attribute auf Teamfotos und einen Kontrastfehler. Solche Punkte sind meist schnell 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 ein paar 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.
Für Entwickler · überspringbar
Profi-Block: Barrierefreiheit automatisiert mittesten
Die sieben Prüfungen oben sind manuell. Wer regelmäßig deployt, will den automatisch abdeckbaren Teil nicht bei jedem Release von Hand wiederholen. Die Engine hinter Axe, axe-core, lässt sich in die Test-Pipeline einbauen und den Build abbrechen, sobald ein automatisch prüfbarer Verstoß hinzukommt. Ein Beispiel mit Playwright, das die Startseite gegen WCAG 2.1 AA prüft:
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
test('Startseite ohne A11y-Verstoesse', async ({ page }) => {
await page.goto('https://ihre-domain.de/');
const ergebnis = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa'])
.analyze();
expect(ergebnis.violations).toEqual([]);
});Wichtig bleibt die ehrliche Einordnung von oben: Dieser Lauf deckt nur den automatisch prüfbaren Teil ab, also rund die Hälfte. Er ersetzt die manuelle Tastatur- und Screenreader-Prüfung nicht. Aber er hält die einfache Hälfte dauerhaft sauber und verhindert Rückschritte beim nächsten Theme-Update. Wer kein eigenes Test-Setup pflegt, bekommt mit dem Kommandozeilen-Werkzeug pa11y in einer Zeile einen ähnlichen Effekt.
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 mehr als eine Fehlerliste: 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.
Pflicht oder Rendite? Warum sich Barrierefreiheit doppelt lohnt
Aus meiner Sicht ist die reine Pflicht-Perspektive die schwächere. Sie führt zu Minimal-Compliance: gerade so viel, dass die Barrierefreiheitserklärung formal steht. Zwei Blickwinkel führen weiter, und sie zeigen auf dieselbe Maßnahmenliste.
Recht-Sicht. Das BFSG macht WCAG für viele Unternehmen zur Pflicht. Wer nicht liefert, riskiert Abmahnung und im Ernstfall die Marktaufsicht. Das ist real, aber es ist ein Vermeidungsmotiv: Man handelt, um Schaden abzuwenden.
Wirkungs-Sicht. Barrierefreiheit ist kein Sonderfall für eine kleine Gruppe. Ein sichtbarer Fokus hilft jedem, der schnell mit der Tastatur arbeitet. Hohe Kontraste helfen bei Sonnenlicht auf dem Handy und älteren Augen. Klare Formularlabels senken die Abbruchquote im Checkout für alle. Der Punkt, der beide Welten verbindet: Die Maßnahmen überschneiden sich fast eins zu eins mit gutem SEO. Aussagekräftige Alt-Texte, eine saubere Überschriftenhierarchie, sprechende Linktexte und Untertitel für Videos sind gleichzeitig WCAG-Kriterien und Rankingsignale. Ein Screenreader und der Google-Crawler lesen eine Seite auf erstaunlich ähnliche Weise: Beide sehen kein Bild, beide brauchen Struktur im Code.
An einer Stelle trennen sich die Wege. Die formale Konformitätsbewertung und die Barrierefreiheitserklärung selbst zahlen nur auf die Pflicht ein, nicht auf Umsatz oder Ranking. Alles davor, die eigentliche technische Umsetzung, zahlt auf beides.
Wer nach WCAG baut, erfüllt das Gesetz und nimmt die Wirkung auf Ranking und Conversion mit. Wer nur die Pflicht abhakt, zahlt den vollen Aufwand für die halbe Wirkung.
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. Rechtlich verbindlich ist über EN 301 549 derzeit WCAG 2.1 AA, 2.2 ist der vorausschauende Maßstab.
- Wer eine Barrierefreiheitserklärung veröffentlichen will, die standhält, kommt an einer Prüfung mit echtem Screenreader nicht vorbei.
- Dieselben Maßnahmen erfüllen die BFSG-Pflicht und verbessern zugleich SEO, Mobilnutzung und Conversion für alle Besucher. Der Pflicht-Aufwand bringt die Wirkung gratis mit.
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.
Bringt Barrierefreiheit auch Vorteile für das Google-Ranking?
Ja, indirekt, aber spürbar. Mehrere WCAG-Kriterien sind zugleich Rankingsignale, etwa Alternativtexte, eine saubere Überschriftenhierarchie und sprechende Linktexte. Eine technisch barrierefreie Seite ist deshalb fast immer auch eine suchmaschinenfreundliche Seite. Den Mechanismus dahinter erklärt der Abschnitt „Pflicht oder Rendite?“ weiter oben.