Ob eine Website barrierefrei ist, lässt sich zu einem guten Teil ohne bezahltes Werkzeug prüfen. Du brauchst einen Browser, eine Tastatur und eine halbe Stunde. Die zwölf Tests unten decken die Fehler ab, die am häufigsten vorkommen. Sie ersetzen kein vollständiges Gutachten, aber sie zeigen schnell, ob eine Seite grundsätzlich in Ordnung ist oder ob es größere Baustellen gibt.
Maßstab sind die Web Content Accessibility Guidelines des W3C in Version 2.2, Stufe AA. Bei jedem Test steht das passende Erfolgskriterium in Klammern, damit du nachlesen kannst.
Erst klären: Gilt das BFSG für dich?
Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz. Es erfasst nicht jede Website. Gemeint sind „Dienstleistungen im elektronischen Geschäftsverkehr“, also Angebote, über die Verbraucher online einen Vertrag schließen, etwa ein Onlineshop oder eine Online-Buchung.
Kleinstunternehmen, die Dienstleistungen anbieten, sind ausgenommen. Als Kleinstunternehmen gilt nach § 2 BFSG, wer weniger als zehn Personen beschäftigt und höchstens zwei Millionen Euro Jahresumsatz oder Jahresbilanzsumme hat. Eine reine Info-Website eines Handwerksbetriebs mit Telefonnummer und Kontaktformular fällt in der Regel nicht unter das Gesetz.
Prüfen lohnt sich trotzdem. Eine barrierefreie Seite ist für alle leichter zu bedienen, am Telefon, bei Sonnenlicht, mit müden Augen. Und wer später einen Shop oder eine Buchung ergänzt, hat die Grundlage schon.
Die zwölf Tests
1. Nur mit der Tastatur bedienen (2.1.1)
Leg die Maus weg. Geh mit Tab vorwärts, mit Umschalt+Tab zurück, öffne Links und Knöpfe mit Enter, Auswahlfelder mit den Pfeiltasten. Erreichst du jedes Menü, jeden Knopf, jedes Formularfeld? Kommst du aus einem geöffneten Menü oder Dialog wieder heraus? Wenn du irgendwo festhängst, ist das ein schwerer Fehler.
2. Fokus sehen (2.4.7 und 2.4.11)
Beim Tabben muss immer sichtbar sein, wo du gerade bist, mit einem deutlichen Rahmen oder einer Unterstreichung. Neu in WCAG 2.2: Das fokussierte Element darf nicht vollständig von einer festen Kopfzeile, einem Cookie-Hinweis oder einem Chat-Fenster verdeckt sein.
3. Auf 200 Prozent vergrößern (1.4.4)
Stell den Browser-Zoom auf 200 Prozent. Der Text muss lesbar bleiben, nichts darf abgeschnitten werden oder sich überlappen.
4. Auf 400 Prozent vergrößern (1.4.10)
Bei 400 Prozent entspricht die Seite an einem üblichen Laptop etwa einer Breite von 320 Pixeln. Jetzt darf es keinen waagerechten Scrollbalken für Fließtext geben, die Inhalte müssen untereinander rutschen. Gleichzeitig prüfst du so die Telefonansicht. Laut Web Almanac 2025 verhindern 19 Prozent der mobilen Seiten das Zoomen ganz oder teilweise. Das ist ein Fehler im Code und schnell behoben.
5. Kontrast messen (1.4.3 und 1.4.11)
Normaler Text braucht ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund, großer Text 3:1. Bedienelemente wie Rahmen von Eingabefeldern brauchen 3:1. Die Entwicklerwerkzeuge in Chrome, Edge und Firefox zeigen den Kontrast, wenn du ein Textelement untersuchst. Kontrast ist der häufigste Fehler überhaupt: In der Messung WebAIM Million 2026 hatten 83,9 Prozent der meistbesuchten Startseiten Text mit zu geringem Kontrast. Typische Kandidaten sind hellgrauer Text, Text auf Fotos und Platzhaltertext in Formularen.
6. Überschriften-Gerüst prüfen (1.3.1)
Jede Seite braucht genau eine Hauptüberschrift (h1), darunter h2, h3 in sinnvoller Reihenfolge. Das Prüfwerkzeug WAVE zeigt das Gerüst als Liste. Wenn es sich wie ein Inhaltsverzeichnis liest, ist es gut. Überschriften, die nur wegen der Schriftgröße gewählt wurden, fallen hier sofort auf.
7. Alternativtexte für Bilder (1.1.1)
Jedes Bild, das etwas aussagt, braucht einen Alternativtext, der das Gleiche sagt. „Team vor der Werkstatt in Tostedt“ ist gut, „IMG_2041“ oder „Bild“ nicht. Rein dekorative Bilder bekommen ein leeres alt="", damit Screenreader sie überspringen.
8. Formulare mit Beschriftung und verständlichen Fehlern (3.3.1 und 3.3.2)
Jedes Feld braucht eine sichtbare Beschriftung, nicht nur einen grauen Platzhalter, der beim Tippen verschwindet. Schick das Formular einmal leer ab: Steht beim Feld, was fehlt, und kommst du direkt zum ersten Fehler? Eine Fehlermeldung nur in Rot reicht nicht.
9. Linktexte, die für sich stehen (2.4.4)
„Hier klicken“ und „Mehr“ sagen ohne Umgebung nichts. Screenreader-Nutzer lassen sich oft alle Links einer Seite als Liste anzeigen. „Preise für die Heizungswartung“ funktioniert auch dort.
10. Klickflächen groß genug (2.5.8)
Neu in WCAG 2.2: Klickziele müssen mindestens 24 mal 24 Pixel groß sein oder genug Abstand zu Nachbarn haben. Kritisch sind kleine Symbole im Footer, eng stehende Links und das Schließen-Kreuz von Hinweisen.
11. Bewegung anhalten und Sprache angeben (2.2.2 und 3.1.1)
Was sich länger als fünf Sekunden von selbst bewegt, etwa ein Slider oder ein Video im Hintergrund, braucht einen Knopf zum Anhalten. Außerdem muss die Seite ihre Sprache angeben (lang="de" im HTML), damit Screenreader richtig vorlesen. Den Wert siehst du in den Entwicklerwerkzeugen ganz oben im Code.
12. Automatischer Test als Ergänzung
Zum Schluss ein kostenloses Prüfwerkzeug: WAVE von WebAIM als Browser-Erweiterung oder die Lighthouse-Prüfung in Chrome. Sie finden fehlende Beschriftungen, Kontrastfehler und leere Links zuverlässig. Was sie nicht beurteilen können, ist, ob ein Alternativtext stimmt oder ob die Bedienung mit der Tastatur sinnvoll ist. Deshalb kommt der automatische Test hier am Ende und nicht am Anfang.
Einen Schritt weiter: Screenreader und Dokumente
Wer mehr Zeit hat, probiert einen Screenreader aus. Auf dem Mac und dem iPhone ist VoiceOver eingebaut, unter Android TalkBack, für Windows gibt es den kostenlosen Screenreader NVDA. Schon zehn Minuten zeigen viel: Wird das Menü verständlich angesagt? Hört man bei einem Knopf, was er tut, oder nur „Schaltfläche“? Werden Bilder sinnvoll beschrieben? Ungewohnt ist es am Anfang, aber man muss kein Profi sein, um grobe Fehler zu hören.
Vergessen werden oft die Dokumente. Speisekarten, Preislisten oder Formulare als PDF sind für Screenreader häufig nicht lesbar, vor allem wenn sie eingescannt sind. Die einfachste Lösung ist meist, den Inhalt zusätzlich als normale Seite anzubieten. Bei Videos gehören Untertitel dazu, bei reinen Tonaufnahmen eine Abschrift.
Und wenn du für Kunden baust: Dokumentiere, was du geprüft hast und mit welchem Ergebnis. Das hilft dir, wenn später jemand fragt, und es hilft dem Kunden, die Erklärung zur Barrierefreiheit zu schreiben, falls er eine braucht.
Ergebnisse sinnvoll sortieren
Nach den zwölf Tests hast du eine Liste. Sortiere sie in drei Gruppen:
| Gruppe | Beispiele | Wann beheben |
|---|---|---|
| Blockiert die Nutzung | Tastaturfalle, Formular nicht absendbar, Zoom gesperrt | sofort |
| Erschwert die Nutzung | zu wenig Kontrast, fehlende Beschriftungen, unsichtbarer Fokus | in den nächsten Tagen |
| Verbesserung | Linktexte, Alternativtexte nachschärfen, Klickflächen | bei der nächsten Überarbeitung |
Betrifft dich das BFSG, gehört zur Website außerdem eine Erklärung zur Barrierefreiheit, die beschreibt, wie die Anforderungen erfüllt werden.
Warum ein Overlay die Prüfung nicht ersetzt
Overlay-Plugins versprechen, eine Seite mit einer Zeile Code barrierefrei zu machen. Sie legen eine Leiste mit Schriftgröße, Kontrast und Vorlesen über die Seite. Die Fehler darunter, etwa ein Menü, das mit der Tastatur nicht erreichbar ist, oder ein Feld ohne Beschriftung, bleiben. Warum das so ist und was Fachleute dazu sagen, steht ausführlich im Ratgeber Barrierefreiheit ohne Plugin.
Einschätzung von Till Heidrich: Der Tastaturtest ist der ehrlichste Test, den es gibt. Er dauert fünf Minuten, kostet nichts, und wer ihn einmal gemacht hat, sieht Websites danach anders.
Ein Design, das schon geprüft ist
Barrierefreiheit ist am günstigsten, wenn sie im Design steckt und nicht nachträglich repariert wird. Alle Designs in der Galerie sind vor dem Verkauf gegen WCAG 2.2 AA geprüft, automatisch und mit einer Prüfliste, und der Bericht liegt im Paket. Was du später hinzufügst, also Texte, Bilder, PDFs und eingebundene Werkzeuge, prüfst du mit den Tests oben selbst. Ein geprüftes Design ist ein guter Anfang, keine Garantie für die fertige Website.