Barrierefreiheit website testen: Der praktische Leitfaden 2026

Aktualisiert am: 07/07/2026

Auf einen Blick: Eine vollständige Barrierefreiheits-Prüfung kombiniert automatisierte Scans, manuelle Tests und echte Nutzer:innen. Hier sind die acht Schritte, die du selbst gehen kannst.

In diesem Artikel

• So testest du deine Website auf Barrierefreiheit Schritt für Schritt

• Barrierefreiheit Website prüfen: automatisiert, manuell oder mit echten Nutzer:innen

• Kostenlose Tools zum Testen der Website-Barrierefreiheit

• Wie du deine Website auch ohne Tools auf Barrierefreiheit prüfst

• Die häufigsten Barrieren auf jeder Website

• Was bei der Barrierefreiheits-Prüfung wirklich zählt

• Welche Standards dein Barrierefreiheits-Test abdecken muss

• Der Accessibility Tree und warum KI-Agenten ihn lesen

• Ergebnisse bewerten, dokumentieren und priorisieren

• Häufig gestellte Fragen zum Barrierefreiheits-Test

Für rund 87 Millionen Menschen mit Behinderungen in Europa entscheiden solche Tests jeden Tag, ob eine Website nutzbar ist.

So testest du deine Website auf Barrierefreiheit 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 kein Budget, nur Zeit und Ehrlichkeit.

Schritt 1: Automatisierten Scan starten

Gib deine URL in einen kostenlosen Checker ein (axe DevTools, WAVE oder Lighthouse). 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, deshalb sind sie besonders wichtig.

Schritt 2: Nur mit der Tastatur navigieren

Leg die Maus beiseite und prüfe:

• Erreichst du mit Tab alle interaktiven Elemente?

• Ist der Fokus jederzeit sichtbar?

• Funktionieren Dropdown-Menüs, Modale und Cookie-Banner?

• Kommst du aus jedem Modal mit Esc heraus?

Deckt WCAG 2.1.1 (Tastatur) und 2.4.7 (Sichtbarer Fokus) ab.

Schritt 3: Mit einem Screenreader testen

Aktiviere NVDA (Windows), VoiceOver (Mac, iOS) oder TalkBack (Android), dann Bildschirm aus oder Augen zu. Hör zu:

• Werden Bilder mit sinnvollen Alt-Texten beschrieben oder hörst du nur „Bild, Bild, Bild"?

• Werden Buttons mit klarer Funktion angekündigt?

• Ergibt die Seitenstruktur für jemanden Sinn, der nichts sieht?

Schritt 4: Farbkontraste prüfen

Der WebAIM Contrast Checker liefert in Sekunden eine Antwort. Achte zusätzlich darauf:

• Werden Fehlermeldungen ausschließlich über Farbe markiert? Ergänze Symbol oder Text.

• Sind Pflichtfeld-Hinweise nur farbig? Ergänze ein Sternchen oder Wort.

• Sind aktive Tabs oder Buttons nur farbig markiert? Ergänze ein anderes visuelles Signal.

WCAG 1.4.1 verlangt, dass Informationen nicht allein durch Farbe vermittelt werden.

Schritt 5: Formulare und interaktive Elemente testen

Formulare entscheiden über Käufe, Anmeldungen und Buchungen. Checkliste:

• Alle Felder mit sichtbaren Labels beschriftet, nicht nur Placeholdern.

• Fehlermeldungen klar formuliert und programmatisch mit dem Feld verknüpft.

• Pflichtfelder, Auswahllisten und Checkboxen vollständig per Tastatur und Screenreader bedienbar.

• Jedes Icon trägt einen sinnvollen Alt-Text oder ein leeres alt-Attribut für dekorative Elemente.

Schritt 6: Multimedia und PDFs nicht vergessen

• Videos: Untertitel vorhanden? Wo nötig auch Audiodeskription?

• PDFs: Liest dein Screenreader sie in der richtigen Reihenfolge? Erkennt er Überschriften, Tabellen und Listen?

• Eingescannte Dokumente: OCR vorhanden oder hört der Screenreader nur Stille?

• Für PDFs eignet sich der kostenlose PDF Accessibility Checker (PAC), der automatisch gegen PDF/UA und WCAG prüft. Word- und PowerPoint-Dateien lassen sich zusätzlich mit der eingebauten Barrierefreiheitsprüfung von Microsoft Office kontrollieren.

  
  

  Mehr dazu in unserem Beitrag zur Barrierefreiheit von digitalen Dokumenten.

Schritt 7: Bei 200 Prozent Zoom prüfen

Drücke Strg/Cmd plus die Plus-Taste, bis die Seite auf 200 Prozent vergrößert ist. Achte auf:

• Bleibt der Inhalt lesbar?

• Gehen Texte verloren oder überlappen sich Elemente?

• Funktioniert die Navigation weiter?

WCAG 1.4.4 verlangt Lesbarkeit ohne Funktionsverlust bis 200 Prozent.

Schritt 8: Echte Nutzer:innen einbeziehen

Werkzeuge finden Fehler, Menschen finden Reibung. Drei bis fünf Tester:innen mit unterschiedlichen Behinderungen reichen für ein klares Bild:

• sehbehinderte oder blinde Tester:innen

• motorisch eingeschränkte Tester:innen

• kognitiv eingeschränkte Tester:innen

Das ist der teuerste, aber auch wertvollste Schritt.

Barrierefreiheit Website prüfen: automatisiert, manuell oder mit echten Nutzer:innen?

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

• `Automatisiert. Scanner wie axe-core, WAVE oder Lighthouse finden in Sekunden fehlende Alt-Texte, niedrige Kontraste und doppelte IDs. Ideal als Erstdiagnose. Grenze: laut WebAIM decken automatisierte Checker nur rund 30 Prozent der WCAG-Kriterien zuverlässig ab.

• Manuell. Mit Tastatur und Screenreader prüfst du, was Algorithmen nicht beurteilen können: logische Struktur, Fokusreihenfolge, ob interaktive Elemente erwartbar reagieren.

• Mit echten Nutzer:innen. Drei bis fünf Tester:innen mit verschiedenen Behinderungen decken reale Reibungspunkte auf, die kein Tool sieht.

`Compliance heißt nicht automatisch Nutzbarkeit. Eine Seite kann technisch konform und in der Praxis trotzdem schwer zu bedienen sein.

Kostenlose Tools zum Testen der Website-Barrierefreiheit

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 Werkzeuge mit einem professionellen Audit, denn kein einzelnes Tool deckt alle WCAG-Kriterien ab.

Wie du deine Website auch ohne Tools auf Barrierefreiheit prüfst

Falls du kein Budget für Software hast, kommst du mit vier Schritten erstaunlich weit:

• Tab-Reise durch die ganze Seite. Erreichst du jedes interaktive Element und siehst du jederzeit, wo der Fokus liegt?

• Bildschirm aus, Screenreader an. NVDA und VoiceOver sind kostenlos. Hör dir an, was tatsächlich vorgelesen wird.

• Browser auf 200 Prozent zoomen. Bricht etwas? Geht Text verloren?

• Heading-Struktur in DevTools prüfen. In Chrome unter Accessibility-Tree-View. Eine sinnvolle Hierarchie ist eines der stärksten Signale für gute Strukturierung.

Diese vier Schritte decken einen großen Teil der häufigsten WCAG-Verstöße auf und kosten nichts außer deiner Zeit.

📋 Die vollständige Checkliste als PDF

Alle WCAG-2.2-Prüfpunkte für Web-Barrierefreiheit, sortiert nach den vier POUR-Prinzipien plus einem Abschnitt zu Konformität und Pflege. Inklusive Implementierungshinweisen für dein Team.

Die häufigsten Barrieren auf jeder Website

In der Praxis tauchen dieselben fünf Fehler auf fast jeder Website auf. Aus unseren Audits in IT, FR, DE und AT wissen wir: Diese fünf machen den größten Teil aller WCAG-Verstöße aus, branchenübergreifend.

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

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

• Formulare ohne Labels. Felder mit reinen Placeholdern. Sobald die Nutzerin tippt, verschwindet der Hinweis, 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.

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

Wer diese fünf systematisch erkennt und angeht, hat den größten Teil der schweren Verstöße bereits abgedeckt.

Was bei der Barrierefreiheits-Prüfung wirklich zählt

Eine vollständige Prüfung deckt alle vier WCAG-Prinzipien ab. Diese drei Bereiche sind in der Praxis die häufigsten Stolperfallen.

Kontrast, Alt-Texte und Struktur

• Kontrast: mindestens 4,5:1 für normalen Text, 3:1 für große Schrift ab 18 pt und UI-Komponenten.

• Alt-Texte: beschreibend für informative Bilder, leeres alt-Attribut für rein dekorative Grafiken.

• Überschriften: logische Hierarchie vom H1 abwärts, keine Ebenen überspringen.

• Farbe nie allein: Fehler, Pflichtfelder und Status nicht ausschließlich über Farbe vermitteln.

Tastaturbedienung, Fokus und Formulare

• Tab-Reise: jedes interaktive Element per Tab erreichbar.

• Fokus immer sichtbar: klarer Fokusring, niemals ausblenden ohne Ersatz.

• Modale schließen mit Esc: keine Tastatur-Fallen.

• Formularfelder mit sichtbaren Labels: Placeholder reichen nicht.

• Fehlermeldungen programmatisch verknüpft: sonst lesen Screenreader sie ohne Kontext.

Verständlichkeit und Screenreader-Tauglichkeit

• Klare Sprache: kurze Absätze, Aktiv, Fachbegriffe bei erster Erwähnung erklären.

• Vorhersehbares Verhalten: Navigation und Buttons reagieren auf jeder Seite gleich.

• Konsistente Lesereihenfolge: Code-Reihenfolge muss zur visuellen Reihenfolge passen.

• Buttons mit klarer Funktion: „Anmelden" statt „Klicken".

Welche Standards dein Barrierefreiheits-Test abdecken muss

• WCAG 2.2: internationaler Standard vom W3C, drei Stufen (A, AA, AAA). Pflicht ist Stufe AA. Mehr in unserem Beitrag Was bedeutet WCAG 2.2?

• BFSG: deutsches Gesetz, seit Juni 2025 für viele B2C-Anbieter Pflicht. Setzt den European Accessibility Act (EAA) um.

• BITV 2.0: gilt für Behörden und öffentliche Stellen in Deutschland.

• EN 301 549: europäische technische Norm, referenziert die WCAG.

• BaFG (Österreich) und BehiG (Schweiz): vergleichbarer Rahmen für DACH.

Bei Verstößen gegen das BFSG drohen Bußgelder bis 100.000 Euro pro Fall, dazu kommen Marktrücknahmen und Imageschäden. Eine digitale Barrierefreiheitsplattform hilft dir, die Konformität dauerhaft im Blick zu behalten.

Der Accessibility Tree, und warum KI-Agenten ihn lesen

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

So öffnest du ihn:

• Elements-Panel öffnen

• Oben rechts auf „Switch to Accessibility Tree View" klicken

• Du siehst jetzt genau das, was Screenreader aus deiner Seite herauslesen

Statt eines HTML-Baums siehst du 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.

Was viele Teams noch unterschätzen: KI-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. Sie fragen:

• Welche Buttons gibt es?

• Welche Links?

• Welche Formulare?

• Was ist deren Funktion?

Ein konkretes Beispiel: Ein:e Nutzer:in bittet einen KI-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 sucht im Baum nach einem Button mit Funktion „Add to cart" oder „In den Warenkorb", findet nichts Passendes, klickt auf irrelevante Elemente wie das Suchfeld und bricht ab. Wäre derselbe Button als <button>In den Warenkorb</button> implementiert, hätte der Agent ihn beim ersten Scan gefunden.

Eine Website, die für Screenreader unsichtbar ist, bleibt auch für KI-Agenten unsichtbar.

Ergebnisse bewerten, dokumentieren und priorisieren

Nach drei Kriterien priorisieren

• Schwere der Auswirkung. Verhindert die Barriere die Nutzung komplett (Login geht nicht ohne Maus) oder erschwert sie sie nur (niedriger Kontrast)?

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

• Geschäftsrelevanz. Liegt die Barriere in einem kritischen Flow wie Checkout oder Kontoeröffnung? Dann zuerst beheben.

So dokumentierst du Mängel sinnvoll

Für jede gefundene Barriere notierst du idealerweise:

• Wo sie auftritt: URL, Komponente und ein Screenshot mit markiertem Element.

• Welches WCAG-Kriterium betroffen ist: Nummer und Stufe, etwa „1.4.3 Kontrast, AA".

• Wie schwer der Verstoß wiegt: kritisch, mittel oder gering.

• Wer den Fix übernimmt: Entwicklung, Design, Redaktion oder PDF-Team.

• Empfohlene Lösung: ein Satz, was geändert werden muss.

Lege die Fehler in Jira, Asana oder einem Ticket-Tool ab, getaggt nach WCAG-Kriterium und Komponente. So erkennst du Muster und fixt geteilte Komponenten in einem Rutsch statt auf jeder Seite einzeln.

Bewährte Reihenfolge für die Umsetzung

1. Kritische Flows reparieren (Login, Checkout, Kontaktformular).

2. Wiederkehrende Komponenten (Header, Footer, Navigation, Cookie-Banner).

3. Seltener besuchte Seiten und einzelne Inhalte.

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

5. Die Barrierefreiheit der Website regelmäßig überprüfen, idealerweise einmal pro Quartal.

Eine ausführliche Anleitung zur Umsetzung findest du in unserem Beitrag Website barrierefrei machen.

Häufig gestellte Fragen zum Barrierefreiheits-Test

Wie oft sollte ich meine Website auf Barrierefreiheit testen?

Mindestens vierteljährlich und zusätzlich nach jedem größeren Release oder Redesign. Plugin-Updates und neue Marketing-Kampagnen können neue Barrieren einführen, deshalb lohnt sich automatisiertes Monitoring fast immer.

Reicht ein Accessibility-Widget für die Compliance?

Nein. Widgets können einzelne Nutzer:innen unterstützen, ersetzen aber keinen Audit und keine Behebung im Quellcode. Die Europäische Kommission hat 2023 klargestellt, dass Overlays allein keine Compliance herstellen.

Was passiert bei Verstößen gegen das BFSG?

Bußgelder bis zu 100.000 Euro pro Fall sind möglich. Marktaufsichtsbehörden können Anordnungen erlassen oder digitale Dienste untersagen, dazu kommen mögliche Verbandsklagen und Reputationsschäden.

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

Für kleinere Seiten teilweise. Kostenlose Werkzeuge wie axe DevTools, WAVE oder Lighthouse decken rund 30 Prozent der WCAG-Kriterien ab. Bei komplexen Customer Journeys oder größeren PDF-Mengen brauchst du Expert:innen-Audits.

Wie teste ich Barrierefreiheit manuell, ganz ohne Tools?

Vier Tests reichen für einen ersten Eindruck: mit der Tastatur durch alle wichtigen Flows tabben, Screenreader bei ausgeschaltetem Bildschirm nutzen, auf 200 Prozent zoomen und die Überschriftenstruktur in den Browser-DevTools prüfen.

Wie dokumentiere ich Mängel und Maßnahmen?

Für jeden Fund hältst du fest: wo er auftritt, welches WCAG-Kriterium betroffen ist, wie schwer der Verstoß wiegt und wer den Fix übernimmt. Eine Ablage in Jira oder Asana mit Tags nach WCAG-Kriterium macht spätere Audits leichter.

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

WCAG ist der internationale technische Standard vom W3C. EN 301 549 ist die europäische harmonisierte Norm, die WCAG um Software, Apps und Hardware erweitert. BFSG ist das deutsche Gesetz, das den European Accessibility Act umsetzt und auf EN 301 549 verweist.

Wie kann ich die digitale Barrierefreiheit meiner Unternehmenswebsite automatisch prüfen und verbessern?

Automatisierte Tools wie axe DevTools, WAVE oder Lighthouse prüfen einzelne Seiten in Sekunden und finden rund 30 Prozent aller WCAG-Verstöße. Für eine Unternehmenswebsite mit vielen Seiten, Templates und regelmäßigen Releases reicht das nicht: du brauchst kontinuierliches Monitoring, das Regressionen nach jedem Deployment erkennt, Issues nach Schwere priorisiert und sie direkt deinem Entwicklungsteam zuweist. Genau das leistet eine digitale Barrierefreiheitsplattform: wiederkehrende Scans, ein zentrales Dashboard, Anbindung an Jira oder Asana und eine Roadmap zur strukturierten Behebung. Komplexe Flows und PDF-Inhalte brauchen zusätzlich manuelle Audits durch Expert:inne