Im Netz kursieren Dutzende Checklisten zur Barrierefreiheit – die meisten sind entweder zu oberflächlich, um zu helfen, oder so lang und kryptisch, dass niemand sie tatsächlich durcharbeitet. Diese barrierefreie Website-Checkliste ist anders aufgebaut: Sie ist nach den vier Grundprinzipien der WCAG gegliedert, und zu jedem Punkt erkläre ich Ihnen nicht nur, was Sie prüfen, sondern auch wie und worauf es ankommt. So können Sie sie wirklich selbst anwenden, ohne Fachjargon entschlüsseln zu müssen. Und ich sage Ihnen offen, wo eine manuelle Checkliste an ihre Grenze stößt – und was Sie dann brauchen.
Wie Sie die barrierefreie Website-Checkliste richtig nutzen
Bevor Sie loslegen, ein Rat aus der Praxis: Haken Sie diese Punkte nicht blind ab, sondern verstehen Sie jeden einzelnen. Eine Checkliste ist kein Formular zum schnellen Erledigen, sondern ein Werkzeug, das Ihren Blick schult. Arbeiten Sie sie an ein paar typischen Seiten Ihrer Website durch – Startseite, ein Formular, eine Inhaltsseite –, denn dort zeigen sich die meisten Muster. Die folgende barrierefreie Website-Checkliste ist nach den WCAG-Prinzipien wahrnehmbar, bedienbar, verständlich und robust gegliedert. Diese vier Kategorien strukturieren auch den offiziellen WCAG-Standard und helfen Ihnen, kein Themenfeld zu übersehen.
Ein Wort zur Priorisierung: Nicht jeder Punkt wiegt gleich schwer. Eine fehlende Tastaturbedienung oder unlesbare Kontraste sperren Nutzer vollständig aus, während ein suboptimaler Linktext nur stört. Wenn Ihre Zeit begrenzt ist, beginnen Sie mit den Punkten, die ganze Nutzergruppen ausschließen – die fünf wichtigsten dazu gleich. Und bedenken Sie: Eine barrierefreie Website-Checkliste ist keine einmalige Übung. Jede neue Seite, jedes Plugin-Update und jeder neue Inhalt kann frische Barrieren einführen, weshalb Sie die Prüfung regelmäßig wiederholen sollten – nicht nur einmal zum Launch, sondern als festen Bestandteil Ihrer Pflege.
Wahrnehmbar: Was alle sehen und hören können müssen
Das erste Prinzip stellt sicher, dass Inhalte für alle Sinne zugänglich sind – auch für Menschen, die nicht sehen oder schlecht sehen. Es ist der Bereich, in dem sich die meisten Fehler noch mit dem bloßen Auge finden lassen, und deshalb ein guter Einstieg in jede barrierefreie Website-Checkliste.
Farbkontraste (1.4.3). Prüfen Sie, ob normaler Text mindestens ein Kontrastverhältnis von 4,5:1 zum Hintergrund hat, bei großer Schrift genügen 3:1. Der mit Abstand häufigste Fehler, den ich sehe, ist hellgraue Schrift auf weißem Grund – modern, aber für viele schlicht nicht lesbar. Ein kostenloser Kontrast-Checker im Browser klärt das in Sekunden.
Alternativtexte für Bilder (1.1.1). Jedes informative Bild braucht einen Alt-Text, der seine Aussage wiedergibt; rein dekorative Bilder erhalten ein leeres Alt-Attribut, damit der Screenreader sie überspringt. Nichtssagende Texte wie „Bild1″ oder ein komplett fehlendes Attribut sind klassische Durchfaller.
Text bleibt skalierbar (1.4.4 und 1.4.10). Zoomen Sie die Seite im Browser auf 200 Prozent. Bleibt alles lesbar und bedienbar, ohne dass Text abgeschnitten wird oder sich Elemente überlappen? Feste Pixelhöhen für Textcontainer sind hier die typische Falle.
Nicht allein über Farbe (1.4.1). Information darf nie ausschließlich über Farbe vermittelt werden. Ein Pflichtfeld, das nur durch einen roten Rahmen markiert ist, bleibt für farbenblinde Nutzer unsichtbar – ergänzen Sie ein Symbol oder einen Text.
Untertitel und Transkripte (1.2.2). Videos brauchen Untertitel, reine Audioinhalte ein Transkript. Ohne diese Alternativen sind die Inhalte für gehörlose oder schwerhörige Menschen verloren. Wichtig: Automatisch generierte Untertitel – etwa die von YouTube oder anderen Plattformen – genügen für sich genommen nicht. Sie verschlucken Eigennamen, Fachbegriffe und Satzzeichen und müssen vor der Veröffentlichung gegengelesen und korrigiert werden; erst geprüfte Untertitel erfüllen das Kriterium.
Aus der Praxis: Bei einem Relaunch hatte ein Designteam ein elegantes Hellgrau für sämtliche Fließtexte gewählt – Kontrastwert 2,9:1. In der Sehbehinderten-Simulation verschwand der halbe Text. Der Fix war minimal, ein dunkleres Grau, aber niemand hatte den Kontrast je gemessen. Genau dafür ist Punkt eins der Checkliste da.
Bedienbar: Alles muss ohne Maus funktionieren
Das zweite Prinzip dreht sich um die Bedienung – insbesondere für Menschen, die keine Maus nutzen, sondern Tastatur oder assistive Eingabegeräte. Diese Punkte betreffen weit mehr Menschen, als man zunächst denkt: von dauerhaft motorisch eingeschränkten Nutzern bis zu jemandem, der gerade nur eine Hand frei hat.
Vollständige Tastaturbedienung (2.1.1). Legen Sie die Maus weg und navigieren Sie nur mit der Tab-Taste. Erreichen und bedienen Sie wirklich alles – Menüs, Schaltflächen, Formulare, Schließen-Kreuze? Was Sie mit der Tastatur nicht erreichen, existiert für viele Nutzer nicht. Achten Sie besonders auf selbstgebaute Menüs, Bildergalerien und Schließen-Kreuze in Pop-ups – das sind die Stellen, an denen die Tastaturbedienung am häufigsten vergessen wird.
Sichtbarer Tastaturfokus (2.4.7). Sehen Sie beim Tabben deutlich, wo Sie gerade sind? Ein klarer Fokusrahmen ist Pflicht. Sehr verbreitet ist der Fehler, ihn aus optischen Gründen per CSS zu entfernen – damit wird die Seite für sehende Tastaturnutzer unbenutzbar.
Keine Tastaturfalle (2.1.2). Kommen Sie mit der Tastatur überall wieder heraus, etwa aus einem geöffneten Dialogfenster? Wenn der Fokus in einem Element gefangen bleibt, ist die ganze Seite blockiert.
Logische Fokus-Reihenfolge (2.4.3). Tabben Sie einmal langsam durch und achten Sie darauf, ob der Fokus in einer sinnvollen Reihenfolge wandert – meist von oben nach unten, links nach rechts. Springt er wild umher, stimmt die Reihenfolge im Quelltext nicht mit der sichtbaren Anordnung überein. Das passiert besonders oft, wenn Elemente per CSS (Flexbox oder Grid) optisch umsortiert wurden, der Code aber die alte Reihenfolge behält – ein Fehler, den man nur beim Tabben bemerkt, nie beim Hinsehen.
Fokus nicht verdeckt (2.4.11). Achten Sie darauf, dass beim Tabben kein klebriger Header und kein Cookie-Banner das fokussierte Element verdeckt – ein Kriterium, das mit WCAG 2.2 neu hinzugekommen ist und in der Praxis ständig verletzt wird.
Ausreichend große Klickflächen (2.5.8). Interaktive Elemente sollten mindestens 24 mal 24 Pixel groß sein. Winzige Icon-Buttons und eng gesetzte Pfeile lassen Menschen mit motorischen Einschränkungen regelmäßig danebentreffen.
Sprunglink zum Inhalt (2.4.1). Ein „Zum Inhalt springen“-Link am Seitenanfang erspart Tastaturnutzern, sich bei jeder Seite durch die komplette Navigation zu tabben.
Verständlich: Inhalte und Bedienung müssen klar sein
Das dritte Prinzip sorgt dafür, dass Nutzer verstehen, was sie sehen und wie sie die Seite bedienen. Hier geht es weniger um Technik als um Klarheit – und von Klarheit profitiert am Ende jeder Besucher, nicht nur Menschen mit Einschränkungen.
Dokumentsprache festgelegt (3.1.1). Im HTML muss die Sprache der Seite gesetzt sein, damit der Screenreader die richtige Aussprache wählt; fremdsprachige Passagen werden gesondert ausgezeichnet. Fehlt die Angabe, liest ein Screenreader deutschen Text womöglich mit englischer Betonung vor. In den meisten Content-Management-Systemen lässt sich die Sprache zentral einstellen; im Seitenquelltext erkennen Sie an einem Attribut wie lang="de" im html-Tag, ob sie tatsächlich gesetzt ist.
Beschriftete Formularfelder (3.3.2). Jedes Eingabefeld braucht ein sichtbar verknüpftes Label. Ein bloßer Platzhaltertext im Feld genügt nicht, denn er verschwindet beim Tippen und ist für Screenreader unzuverlässig.
Verständliche Fehlermeldungen (3.3.1). Wenn ein Formular einen Fehler meldet, muss klar in Textform stehen, welches Feld betroffen ist und was zu tun ist. Eine rein farbliche Markierung oder ein vages „Fehler aufgetreten“ hilft niemandem weiter.
Konsistente Navigation (3.2.3). Die Navigation sollte auf allen Seiten an gleicher Stelle und in gleicher Reihenfolge erscheinen. Wer Orientierung sucht, soll sie nicht auf jeder Seite neu suchen müssen.
Sprechende Linktexte (2.4.4). Ein Linktext muss aus sich heraus verständlich sein – „Preise ansehen“ statt „hier klicken“. Screenreader-Nutzer lassen sich oft nur die Liste aller Links vorlesen, und „hier, hier, hier“ ist dann wertlos.
Aus der Praxis: Ein Buchungsformular meldete Fehler nur durch rot umrandete Felder – ohne ein Wort Text. Ein blinder Nutzer wusste so zwar, dass etwas nicht stimmte, aber nicht, welches Feld und warum. Der Screenreader las brav die Felder vor, doch die Fehlerinformation steckte allein in der Farbe. Eine ausgeschriebene Meldung wie „Bitte geben Sie ein gültiges Datum ein“ löste das Problem vollständig.
Robust: Technik, die mit Hilfsmitteln zusammenarbeitet
Das vierte Prinzip stellt sicher, dass Ihre Seite auch mit assistiven Technologien zuverlässig funktioniert – heute und in Zukunft. Es ist der technischste der vier Bereiche, aber auch der, der über die Zukunftssicherheit Ihrer Seite entscheidet, wenn sich Browser und Hilfsmittel weiterentwickeln.
Saubere Überschriften-Struktur (1.3.1). Verwenden Sie genau eine h1 pro Seite und gliedern Sie den Rest lückenlos mit h2 und h3. Screenreader navigieren über diese Struktur; Sprünge oder optische Pseudo-Überschriften zerstören die Orientierung. Viele Browser-Erweiterungen zeigen Ihnen die Überschriften-Gliederung einer Seite auf einen Blick und decken Lücken sofort auf.
ARIA sparsam und korrekt (4.1.2). Nutzen Sie native HTML-Elemente, wo immer es geht, und greifen Sie nur dort zu ARIA, wo Standard-HTML nicht ausreicht. Falsch gesetzte ARIA-Attribute richten mehr Schaden an als gar keine.
Statusmeldungen werden angekündigt (4.1.3). Dynamische Rückmeldungen – „In den Warenkorb gelegt“, ein eingeblendeter Formularfehler, ein Filter-Ergebnis, das sich aktualisiert – müssen Screenreadern aktiv gemeldet werden, ohne dass sich der Fokus bewegt. Technisch geschieht das über einen aria-live-Bereich. Fehlt er, ändert sich die Seite sichtbar, aber ein blinder Nutzer erfährt nichts davon und wartet vergeblich auf eine Reaktion. Dieser mit WCAG 2.1 eingeführte Punkt wird auf modernen, dynamischen Seiten am häufigsten übersehen.
Test mit echtem Screenreader. Der wichtigste und meistübersprungene Punkt: Gehen Sie Ihre Seite einmal mit einem Screenreader wie NVDA oder VoiceOver durch. Erst dann hören Sie, was Ihre Nutzer hören – und entdecken Probleme, die kein Blick auf den Bildschirm verrät.
Nutzbar auf dem Smartphone. Prüfen Sie, ob sich die Seite auf kleinen Bildschirmen ohne horizontales Scrollen nutzen lässt und Inhalte sauber umbrechen. Was am Desktop funktioniert, kann mobil unbedienbar sein. Zoomen Sie zusätzlich tief hinein – spätestens dort zeigen sich Layouts, die nur für eine feste Breite gebaut wurden und bei denen Inhalte verloren gehen.
Aus der Praxis: Ein Kunde hatte seine eigene Checkliste vorbildlich abgehakt – Kontraste, Labels, Tastatur, alles grün. Den Screenreader-Test hatte er ausgelassen, „aus Zeitgründen“. In zehn Minuten mit NVDA fanden wir, dass seine selbstgebaute Navigation bei jedem Menüpunkt nur „Link“ vorlas, ohne den Namen. Auf dem Papier perfekt, in der Praxis eine Sackgasse.
Diese fünf Punkte prüfen Sie zuerst
Wenn Sie die vollständige barrierefreie Website-Checkliste nicht auf einmal schaffen, konzentrieren Sie sich auf die fünf Prüfungen, die in unseren Audits am häufigsten ganze Nutzergruppen aussperren. Sie bringen den größten Effekt pro investierter Minute.
Erstens die Tastaturbedienung: Lässt sich wirklich alles ohne Maus erreichen? Zweitens der sichtbare Fokus: Sehen Tastaturnutzer jederzeit, wo sie sich befinden? Drittens die Farbkontraste: Ist der Text auch bei schwacher Sehkraft lesbar? Viertens die Formular-Labels: Weiß ein Screenreader, was in jedes Feld gehört? Und fünftens der Screenreader-Test selbst – die eine Prüfung, die mehr aufdeckt als jede andere. Diese fünf Punkte beheben die schwerwiegendsten Barrieren; alles Weitere baut darauf auf. Wer nur diese Kurzliste abarbeitet, hat bereits mehr getan als die große Mehrheit aller Websites.
Welche Werkzeuge Ihnen beim Prüfen helfen
Sie müssen nicht jeden Punkt mit bloßem Auge prüfen – einige Werkzeuge nehmen Ihnen Arbeit ab. Für Farbkontraste gibt es kostenlose Kontrast-Checker, die Ihnen das exakte Verhältnis anzeigen. Browser-Erweiterungen aus der WAVE- oder axe-Familie markieren automatisch fehlende Alt-Texte, Strukturfehler und ARIA-Probleme direkt auf der Seite. Den wichtigsten Test aber nimmt Ihnen kein Werkzeug ab: das Durchgehen mit einem echten Screenreader. NVDA ist für Windows kostenlos, VoiceOver auf dem Mac bereits eingebaut – beide kosten Sie nichts außer einer halben Stunde Einarbeitung. Welches Werkzeug wofür taugt und wo die automatischen Prüfer an ihre Grenzen stoßen, habe ich im Vergleich der Test-Tools ausführlich beschrieben. Die Regel lautet: Kombinieren Sie immer automatische Prüfung mit manueller Kontrolle, denn keines von beidem allein genügt.
Ein Profi-Trick für die schnelle Strukturprüfung: Deaktivieren Sie im Browser einmal das Stylesheet – über die Entwicklertools oder den Lesemodus. Die Seite erscheint dann als nackter, linearer Textfluss, und genau diese Reihenfolge bekommt auch ein Screenreader zu hören. Wirkt der Inhalt in dieser Ansicht durcheinander – steht die Navigation plötzlich mitten im Text oder rutscht eine Seitenleiste vor den Hauptinhalt –, dann stimmt die Lesereihenfolge im Code nicht. Ein Zehn-Sekunden-Test, der mehr über die zugrunde liegende Struktur verrät als jeder optische Eindruck.
Die Schnell-Checkliste zum Mitnehmen
Hier alle Punkte kompakt zusammengefasst. Drucken Sie sie aus oder speichern Sie sie – als Schnellkontrolle vor jeder Veröffentlichung.
| Prinzip | Prüfpunkte |
|---|---|
| Wahrnehmbar | Kontrast ≥ 4,5:1 (1.4.3), Alt-Texte (1.1.1), 200 % Zoom funktioniert (1.4.4/1.4.10), Information nicht nur über Farbe (1.4.1), Untertitel und Transkripte (1.2.2) |
| Bedienbar | Vollständig per Tastatur (2.1.1), sichtbarer Fokus (2.4.7), logische Fokus-Reihenfolge (2.4.3), keine Tastaturfalle (2.1.2), Fokus nicht verdeckt (2.4.11), Klickflächen ≥ 24 px (2.5.8), Sprunglink (2.4.1) |
| Verständlich | Dokumentsprache gesetzt (3.1.1), Felder beschriftet (3.3.2), Fehlermeldungen in Textform (3.3.1), konsistente Navigation (3.2.3), sprechende Linktexte (2.4.4) |
| Robust | Eine h1 plus saubere Hierarchie (1.3.1), ARIA sparsam und korrekt (4.1.2), Statusmeldungen angekündigt (4.1.3), Screenreader-Test bestanden, mobil ohne Querscrollen nutzbar |
Was eine barrierefreie Website-Checkliste nicht leisten kann
So nützlich diese barrierefreie Website-Checkliste ist – ich wäre unehrlich, würde ich verschweigen, wo ihre Grenze liegt. Eine manuelle Prüfung deckt vor allem die offensichtlichen, sichtbaren Probleme auf. Viele Barrieren stecken aber tiefer im Code oder zeigen sich erst im Zusammenspiel mit bestimmten Hilfsmitteln. Und bei einer Website mit Dutzenden oder Hunderten von Seiten ist es schlicht nicht machbar, jede Seite von Hand komplett durchzugehen.
Hinzu kommt: Manche der heikelsten Barrieren sind mit dem Auge gar nicht zu erkennen. Ob ein selbstgebautes Bedienelement dem Screenreader seine Rolle korrekt meldet, ob ein dynamisch nachgeladener Inhalt überhaupt angekündigt wird, ob die Tab-Reihenfolge im Code der sichtbaren Anordnung folgt – das erschließt sich erst der technischen Prüfung. Eine barrierefreie Website-Checkliste schärft Ihren Blick für das Sichtbare, aber das Unsichtbare bleibt ihr naturgemäß verborgen.
Genau hier setzt unser kostenloser Access Score an. Er scannt Ihre Website automatisch über mehrere Unterseiten gegen die WCAG 2.2, erkennt auch Tastaturfallen und Probleme im Shadow-DOM und übersetzt die rohen technischen Befunde in verständliches Deutsch – kein Fachjargon, sondern klare Aussagen, wo Sie stehen. Andere Anbieter geben Ihnen eine Liste in die Hand und lassen Sie damit allein; Access Score liefert Ihnen einen objektiven Status auf Knopfdruck und einen nachvollziehbaren Bericht. Sie sehen mit wenigen Klicks, wie viele Seiten betroffen sind und welche Fehler am häufigsten auftreten – einen Überblick, den Sie sich mit reiner Handarbeit über Stunden erst erarbeiten müssten. Ich sage Ihnen aber auch hier ehrlich: Auch ein automatischer Scan erkennt nur einen Teil aller Kriterien. Er ist der ideale Einstieg, um Ihren Status zu sehen – die vollständige Gewissheit liefert erst die Prüfung mit echten Nutzern. So oder so beginnt jeder seriöse Weg zur Barrierefreiheit mit einer ehrlichen Bestandsaufnahme, und genau die liefert Ihnen Access Score in wenigen Minuten, ohne dass Sie etwas installieren oder bezahlen müssen.
Vom Selbstcheck zum objektiven Status
Die Checkliste schult Ihren Blick, der automatische Scan liefert den objektiven Befund, und das menschliche Audit bringt die belastbare Gewissheit – in dieser Reihenfolge bauen die Schritte aufeinander auf. Diese barrierefreie Website-Checkliste ist damit kein Endpunkt, sondern Ihr Startpunkt: ein Werkzeug, mit dem Sie die offensichtlichen Barrieren selbst beseitigen, bevor Profis das Feine übernehmen. Sie haben mit dieser Liste den Anfang gemacht; den nächsten Schritt nehme ich Ihnen gern ab.
Wenn Sie wissen wollen, wie Ihre Seite jenseits der sichtbaren Punkte wirklich dasteht, ist ein kostenloser WCAG-Test Ihrer Website der mühelose nächste Schritt – in Minuten, ohne Verpflichtung. Zeigt der Score Handlungsbedarf, führt der Weg zur rechtssicheren Konformität nach BFSG über Access Ready, unser zertifiziertes Tiefen-Audit mit echten Nutzern. Ich verspreche Ihnen keine perfekte Seite per Knopfdruck – aber einen klaren Weg vom ersten Selbstcheck bis zum belastbaren Nachweis.
