Wie prüfe ich ob meine website barrierefrei ist: Der praktische Leitfaden 2026

Stell dir vor, du willst online ein Hotelzimmer buchen und kommst nicht über den Datepicker hinaus, weil deine Tastatur ihn nicht öffnet. 

Für rund 87 Millionen Menschen mit Behinderungen in Europa ist das keine Übung, sondern Alltag. 

Seit dem 28. Juni 2025 ist digitale Barrierefreiheit gesetzliche Pflicht. In diesem Leitfaden zeigen wir dir, wie du deine Website auf Barrierefreiheit testest, welche Tools helfen, welche Anforderungen die Gesetze stellen und wie du die häufigsten Barrieren schnell erkennst.

Überblick darüber, wie Sie die Barrierefreiheit Ihrer Website überprüfen können

Schritt 1: Automatisierten Scan starten

Schritt 2: Nur mit der Tastatur navigieren

Schritt 3: Mit einem Screenreader testen

Schritt 4: Farbkontraste prüfen

Schritt 5: Formulare und interaktive Elemente testen

Schritt 6: Multimedia und PDFs nicht vergessen

Schritt 7: Bei 200 Prozent Zoom prüfen

Schritt 8: Echte Nutzer:innen einbeziehen

Warum du deine Website jetzt testen solltest

Ein Accessibility-Test ist mehr als eine Pflichtübung. Er zeigt schwarz auf weiß, wo deine Inhalte Menschen ausschließen, und wo du unbemerkt Umsatz verlierst. 

Hinzu kommt der SEO-Effekt. Suchmaschinen-Crawler und Screenreader sind erstaunlich ähnliche Nutzer:innen, beide lesen sequenziell und hängen an semantischer Struktur. Saubere Überschriften, beschreibende Alternativtexte und gut strukturierte Formulare helfen Google genauso wie blinden Nutzer:innen. Digitale Barrierefreiheit ist damit kein reines Compliance-Thema, sondern ein technischer Hebel für Performance und Sichtbarkeit, vor allem in Branchen wie E-Commerce, Banking und Verkehr.

Audit anfragen

So testest du deine Website Schritt für Schritt

Wir nutzen mit unseren Kund:innen einen Acht-Schritte-Rahmen, der die WCAG-Prinzipien abdeckt und auch in kleineren Teams umsetzbar ist. Du brauchst dafür kein Budget, nur Zeit und Ehrlichkeit. Nutze die folgende Checkliste, um die Barrierefreiheit Website-weit zu überprüfen und die wichtigsten Barrieren zu erkennen.

Schritt 1: Automatisierten Scan starten

Gib deine URL in einen kostenlosen Browser-basierten Checker ein, zum Beispiel accessScan, WAVE oder Lighthouse. Notiere wiederkehrende Fehler und wiederhole den Scan auf mindestens fünf repräsentativen Seitentypen: Startseite, Kategorieseite, Produktseite, Formular, Checkout. Wiederkehrende Komponenten wie Header, Footer oder Cookie-Banner ziehen Fehler durch die ganze Website.

Schritt 2: Nur mit der Tastatur navigieren

Leg die Maus beiseite. Kannst du mit Tab, Shift-Tab, Enter und Pfeiltasten alle interaktiven Elemente erreichen? Ist der Fokus jederzeit sichtbar, sodass du auf einen Blick erkennen kannst, wo du gerade stehst? Funktionieren Dropdown-Menüs, Modale und Cookie-Banner? Kommst du aus jedem Modal mit Esc wieder heraus? Dieser Schritt deckt WCAG 2.1.1 (Tastatur) und 2.4.7 (Sichtbarer Fokus) ab.

Schritt 3, Mit einem Screenreader testen

Aktiviere NVDA auf Windows, VoiceOver auf Mac und iOS oder TalkBack auf Android. Schließ die Augen oder schalte den Bildschirm aus. Werden Bilder mit sinnvollen Alt-Texten beschrieben oder hörst du nur „Bild, Bild, Bild“? Werden Buttons mit klarer Funktion angekündigt, etwa „Anmelden“, oder generisch wie „Klicken“? Macht die Seitenstruktur für jemanden Sinn, der nichts sieht?

Schritt 4: Farbkontraste prüfen

Tools wie der WebAIM Contrast Checker liefern in Sekunden eine Antwort. Mindestwerte nach WCAG AA: 4,5:1 für normalen Text, 3:1 für große Schrift ab 18 pt und für UI-Komponenten wie Buttons. Achte zusätzlich darauf, ob Fehlermeldungen, Pflichtfeld-Markierungen oder Status-Indikatoren ausschließlich auf Farbe vertrauen. Wenn ja, ergänze Symbole oder Text (WCAG 1.4.1).

Schritt 5: Formulare und interaktive Elemente testen

Formulare entscheiden, ob ein Kauf, eine Anmeldung oder eine Buchung gelingt. Prüfe, ob alle Felder mit sichtbaren Labels beschriftet sind, nicht nur mit Placeholdern. Sind Fehlermeldungen klar formuliert und programmatisch mit dem Feld verknüpft? Lassen sich Pflichtfelder, Auswahllisten und Checkboxen vollständig per Tastatur und Screenreader bedienen? Trägt jedes Icon einen sinnvollen Alternativtext oder ein leeres alt-Attribut für rein dekorative Elemente? Diese ehrliche Bewertung deckt die häufigsten Formular-Barrieren auf.

Schritt 6: Multimedia und PDFs nicht vergessen

Haben Videos Untertitel und, wo nötig, eine Audiodeskription? Liest dein Screenreader die PDFs in der richtigen Reihenfolge? Erkennt er Überschriften, Tabellen und Listen, oder hörst du nur einen Textbrei? Bei größeren Dokumentenmengen wird das schnell zur Compliance-Lücke. Mehr dazu liest du in unserem Beitrag zur Barrierefreiheit von digitalen Dokumenten.

Schritt 7: Bei 200 Prozent Zoom prüfen

Drücke Strg oder Cmd plus die Plus-Taste so oft, bis deine Seite auf 200 Prozent vergrößert ist. Bleibt der Inhalt lesbar? Gehen Texte verloren, überlappen Elemente, funktioniert die Navigation weiter? WCAG 1.4.4 verlangt Lesbarkeit ohne Funktionsverlust bis 200 Prozent. Dieser Schritt deckt eine Barriere ab, die vor allem ältere Menschen und Personen mit Sehbehinderung betrifft.

Schritt 8: Echte Nutzer:innen einbeziehen

Tools finden Fehler. Menschen finden Reibung. Drei bis fünf Tester:innen mit unterschiedlichen Behinderungen, also sehbehindert, motorisch eingeschränkt, kognitiv eingeschränkt, liefern dir ein klares Bild der Reibungspunkte, die kein automatisierter Scan je sehen würde. Das ist der teuerste, aber auch wertvollste Schritt.

Welche Standards dein Test abdecken muss

Bevor du loslegst, lohnt sich ein kurzer Blick auf die Anforderungen und Standards, an denen deine Website gemessen wird. Sie bilden das technische Fundament jedes seriösen Tests und helfen dir, die Barrierefreiheit Website-übergreifend nachvollziehbar zu gestalten.

WCAG 2.2 als globaler Maßstab

Die Web Content Accessibility Guidelines 2.2 des W3C sind das international anerkannte Regelwerk. Sie definieren drei Konformitätsstufen, A, AA und AAA. Das BFSG und die EN 301 549 verlangen Stufe AA als Mindestanforderung. Version 2.2 ergänzt unter anderem Kriterien für sichtbare Fokusdarstellung (2.4.11), Drag-and-Drop-Alternativen (2.5.7) und konsistente Hilfsangebote (3.2.6). Die WCAG bauen auf vier Prinzipien auf, oft mit dem Akronym POUR zusammengefasst: Wahrnehmbar, Bedienbar, Verständlich, Robust.

Der rechtliche Rahmen in Deutschland und der EU

Auf europäischer Ebene flankieren zwei Texte das BFSG. Die EU-Webrichtlinie 2016/2102 verpflichtet öffentliche Stellen seit 2018, ihre Websites und Apps barrierefrei zu gestalten.

In Deutschland setzt die BITV 2.0 diese Pflicht für Behörden und öffentliche Stellen technisch um und verweist direkt auf die EN 301 549. 

Der European Accessibility Act erweitert die Pflicht seit 2025 auf den privaten Sektor. Die technische Norm EN 301 549 V3.2.1 konkretisiert die Anforderungen und referenziert die WCAG. Auch BaFG in Österreich und BehiG in der Schweiz folgen einem vergleichbaren Rahmen. Bei Verstößen gegen das BFSG drohen Bußgelder bis zu 100.000 Euro pro Fall, hinzu kommen Marktrücknahmen und Imageschäden.

Wie testest du am besten: automatisiert, manuell oder mit echten Nutzer:innen?

Eine seriöse Prüfung kombiniert immer drei Ebenen. Jede Ebene hat eine klare Aufgabe, und keine kann die andere ersetzen.

• Automatisierte Tests scannen deine Seite in Sekunden. Tools wie axe-core, WAVE oder Lighthouse finden fehlende Alt-Texte, niedrige Kontraste, fehlende Sprachattribute und doppelte IDs. Ideal als Erstdiagnose.

• Die Grenze: Automatisierte Checker decken nur rund 30 Prozent der WCAG-Kriterien zuverlässig ab. Die übrigen 70 Prozent brauchen menschliches Urteilsvermögen.

• Manuelle Prüfung mit Tastatur und Screenreader zeigt, ob Inhalte logisch strukturiert sind, ob die Fokusreihenfolge Sinn ergibt und ob interaktive Elemente erwartbar reagieren.

• User-Tests mit Menschen mit Behinderungen decken reale Reibungspunkte auf, die kein Tool sieht. Schon drei bis fünf Tester:innen liefern ein klares Bild.

• Compliance ≠ Usability: Eine Seite kann technisch konform und in der Praxis trotzdem schwer nutzbar sein. Deshalb gehört die menschliche Perspektive dazu.

Welche kostenlosen Tools kann ich verwenden, um die Barrierefreiheit meiner Website zu testen?

Die Werkzeuglandschaft hat sich stark professionalisiert.

axe DevTools (Deque): Browser-Erweiterung mit Detail-Reports und konkreten Fix-Vorschlägen. Beliebt bei Entwickler:innen.

WAVE (WebAIM): Visualisiert Fehler direkt auf der Seite. Ideal für Redakteur:innen ohne tiefes Code-Wissen.

Lighthouse (Google Chrome): Kombiniert Accessibility-Score mit Performance und SEO. Praktisch für ganzheitliche Reviews.

WebAIM Contrast Checker: Schneller Farbkontrast-Test gegen WCAG AA und AAA.

BIK BITV-Test: Standardisiertes Verfahren mit 92 Prüfschritten. Besonders relevant für die öffentliche Verwaltung.

Screenreader: NVDA (Windows, kostenlos), VoiceOver (Mac/iOS, integriert), TalkBack (Android, integriert). Unverzichtbar für die manuelle Prüfung.

Unser Tipp: Geh selbst zehn Minuten lang nur mit Tastatur und Screenreader durch deine kritischsten Flows. Diese Erfahrung verändert oft das ganze Designdenken. Für eine vollständige Bewertung kombinierst du automatisierte Tools mit einem professionellen Audit, denn kein einzelnes Tool deckt alle WCAG-Kriterien ab.

Der Accessibility Tree in Chrome DevTools, und warum AI-Agenten ihn lesen

Chrome DevTools bietet eine Funktion, die das Testen deutlich greifbarer macht: den vollständigen Accessibility Tree. 

Du öffnest ihn im Elements-Panel und klickst oben rechts auf Switch to Accessibility Tree View. Was du dann siehst, ist genau das, was Screenreader und andere Hilfstechnologien aus deiner Seite herauslesen, kein HTML-Baum, sondern Knoten mit Rollen wie button, link oder heading, mit zugänglichen Namen und ARIA-Eigenschaften. Wo dein Code semantisch leer ist, erscheint ein generic ohne Namen. Wo Bilder einen sinnvollen Alternativtext tragen, lesen Hilfstechnologien diesen Namen. Der Tree macht sichtbar, was sonst unsichtbar bleibt.

Hier kommt eine Entwicklung ins Spiel, die viele Unternehmen noch unterschätzen. AI-Agenten wie OpenAI Atlas, Microsofts Playwright MCP und Vercels agent-browser navigieren Websites nicht über Screenshots oder rohes HTML, sondern über genau diesen Accessibility Tree. Der Baum war ursprünglich für assistive Technologien gedacht, aber Agenten nutzen ihn als Karte deiner Website. 

Sie fragen: 

Welche Buttons gibt es? 

Welche Links? 

Welche Formulare? 

Was ist deren Funktion? 

Eine schwache Accessibility-Implementierung macht deine Website damit auch für Agenten schwer navigierbar.

Ein konkretes Beispiel: Ein:e Nutzer:in bittet einen AI-Agenten, ein Produkt in deinem Shop zu kaufen. Dein In den Warenkorb-Button ist als <div> mit JavaScript-Handler umgesetzt, ohne semantische Rolle, ohne Label. Im Accessibility Tree erscheint der Knoten als generic ohne Namen. Der Agent durchsucht den Baum nach einem Button mit Funktion Add to cart oder In den Warenkorb, findet nichts Passendes, klickt verzweifelt auf irrelevante Elemente wie das Suchfeld oder die Navigation, kommt nicht ans Ziel und bricht den Vorgang ab. Wäre derselbe Button als <button>In den Warenkorb</button> implementiert, hätte der Agent ihn beim ersten Scan als button "In den Warenkorb" gefunden und der Kauf wäre durchgegangen.

Was sind die häufigsten digitalen Barrieren, und wie du sie erkennst

In der Praxis tauchen dieselben fünf Fehler auf fast jeder Webseite immer wieder auf. Du erkennst sie meist schon mit einem oberflächlichen Test.

• Fehlende oder nichtssagende Alternativtexte: Bilder ohne alt-Attribut oder mit Dateinamen als Beschreibung. Erkennbar mit jedem Scanner, sofort behebbar.

• Niedrige Farbkontraste: Hellgraue Texte auf weißem Hintergrund, Buttons mit schwachem Kontrast. Oft Folge von Designentscheidungen, die Barrierefreiheit nicht mitdenken.

• Formulare ohne Labels: Felder mit reinen Placeholdern. Sobald die Nutzerin tippt, verschwindet der Hinweis, und Screenreader-Nutzer:innen wissen ohnehin nicht, was hineingehört.

• Tastatur-Fallen: Modale Fenster, aus denen man mit Tab nicht herauskommt. Cookie-Banner, die den Fokus festhalten. Leicht zu testen, oft übersehen.

• Unzugängliche PDFs: Eingescannte Dokumente ohne OCR, fehlende Tags, falsche Lesereihenfolge. Besonders kritisch bei Verträgen, Rechnungen und Produktdatenblättern.

Diese fünf Muster machen einen großen Teil aller WCAG-Verstöße aus. Wer sie systematisch erkennt und angeht, hat den größten Teil der schweren Verstöße bereits abgedeckt.

Was du nach dem Test tust

Nach dem Test stehst du meist vor einer langen Fehlerliste. Wichtig ist jetzt, nicht alles auf einmal zu tun. Setze Prioritäten nach drei Kriterien.

• Schwere der Auswirkung: Verhindert die Barriere die Nutzung einer Webseite komplett (Login geht nicht ohne Maus) oder erschwert sie sie nur (niedriger Kontrast)? Das ist die wichtigste Frage.

• Reichweite: Sitzt der Fehler in einer Komponente, die auf jeder Seite vorkommt, also Header, Footer oder Navigation? Dann ist der Hebel groß.

• Geschäftsrelevanz: Liegt die Barriere in einem kritischen Flow wie Anmeldung, Checkout oder Kontoeröffnung? Dann zuerst beheben, hier hängen Umsatz und Compliance unmittelbar dran.

Bewährte Reihenfolge für eine inklusive Umsetzung:

• Erst kritische Flows reparieren, das ist der wichtigste Schritt.

• Dann wiederkehrende Komponenten und gemeinsam genutzte Inhalte.

• Dann seltener besuchte Seiten und Inhalte.

• Jede Korrektur einfach dokumentieren, damit sie bei zukünftigen Änderungen nicht versehentlich rückgängig gemacht wird.

• Die Barrierefreiheit der Webseite regelmäßig überprüfen, idealerweise einmal pro Quartal. Das ist deutlich günstiger und einfacher als eine Sanierung kurz vor der nächsten Marktaufsichts-Prüfung der Barrierefreiheit der Website.

Drei Erkenntnisse, die du mitnehmen kannst

Wenn du aus diesem Leitfaden nur drei Dinge mitnimmst, dann diese.

Erstens, automatisierte Scans sind ein Anfang, kein Ende. Sie decken rund 30 Prozent der WCAG-Kriterien ab. Die wirklich relevanten Barrieren findest du nur mit Tastatur, Screenreader und echten Nutzer:innen.

Zweitens, behandle Barrierefreiheit als fortlaufende Praxis, nicht als einmaliges Projekt. Jede neue Seite, jedes Plugin, jede Kampagne kann neue Barrieren einführen. Kontinuierliches Monitoring ist deutlich günstiger als nachträgliche Sanierung.

Drittens, hole Menschen mit Behinderungen früh in den Prozess. Ihre Perspektive macht den Unterschied zwischen technischer Konformität und echter Nutzerfreundlichkeit aus. 

So geht es weiter

Wenn du einen ersten objektiven Blick auf den Stand deiner Website werfen möchtest, kannst du mit einem strukturierten Audit starten. Finde heraus, wie Accessiway dich unterstützen kann oder entdecke unsere Preise und Pakete, um den passenden Einstieg für dein Team zu finden.

Häufig gestellte Fragen zum Test der Barrierefreiheit von Websites

Wie oft sollte ich meine Website auf Barrierefreiheit testen?

Mindestens vierteljährlich, und zusätzlich nach jedem größeren Release oder Redesign. Continuous Monitoring deckt Regressionen früh auf, bevor sie zur Compliance-Lücke werden. Jede neue Webseite, jedes Plugin-Update und jede Marketing-Kampagne kann neue Barrieren einführen, weshalb sich automatisiertes Monitoring fast immer auszahlt. 

Reicht ein Accessibility-Widget für die Compliance?

Nein. Widgets verbessern die Nutzung für einzelne Endnutzer:innen, ersetzen aber keinen Audit und keine Remediation des Quellcodes. Die Europäische Kommission hat 2023 ausdrücklich klargestellt, dass Overlays allein keine Compliance herstellen. Du brauchst die Kombination aus sauberem Code, regelmäßiger Prüfung und einer veröffentlichten Barrierefreiheitserklärung.

Was passiert bei Verstößen gegen das BFSG?

Bußgelder von bis zu 100.000 Euro pro Fall sind möglich. Marktaufsichtsbehörden können Anordnungen erlassen oder digitale Dienste untersagen. Hinzu kommen mögliche Klagen durch Verbände nach dem UKlaG sowie der mittelbare Schaden durch verlorenes Vertrauen und schlechte Presse.

Kann ich meine Website allein mit kostenlosen Tools BFSG-konform machen?

Für kleinere Seiten teilweise. Kostenlose Tools wie axe DevTools, WAVE oder Lighthouse decken rund 30 Prozent der WCAG-Kriterien ab und sind ein guter Einstieg. Spätestens bei komplexen Customer Journeys, dynamischen Inhalten oder größeren PDF-Mengen brauchst du Expert:innen-Audits und manuelle Prüfung durch Menschen mit Behinderungen.

Was ist der Unterschied zwischen WCAG, EN 301 549 und BFSG?

Die WCAG sind der internationale technische Standard, herausgegeben vom W3C. Die EN 301 549 ist die europäische harmonisierte Norm, die WCAG um weitere Technologien wie Software, mobile Apps und Hardware erweitert. Das BFSG ist das deutsche Gesetz, das den European Accessibility Act umsetzt und auf die EN 301 549 verweist. Praktisch heißt das: Wenn deine Website WCAG 2.2 auf Stufe AA erfüllt, erfüllst du den Kern aller drei.