Barrierefreiheits-Audit: Checkliste für Websites und Apps

Warum ein strukturierter Barrierefreiheits-Audit unverzichtbar ist

Digitale Barrierefreiheit ist längst keine freiwillige Kür mehr. Mit dem Inkrafttreten des Barrierefreiheitsstärkungsgesetzes (BFSG) und der europäischen Richtlinie EN 301 549 stehen Unternehmen und Behörden vor konkreten rechtlichen Verpflichtungen. Ein Barrierefreiheits-Audit ist dabei das zentrale Instrument, um den tatsächlichen Zustand eines digitalen Angebots objektiv zu bewerten – und gezielte Verbesserungsmaßnahmen abzuleiten. Was viele unterschätzen: Accessibility betrifft weit mehr als die Nutzung von Screenreadern. Kognitive Einschränkungen, motorische Behinderungen, Sehschwächen oder vorübergehende Beeinträchtigungen wie ein gebrochenes Handgelenk machen Barrierefreiheit zu einem universellen Qualitätsmerkmal.

Ein professioneller Audit folgt einem klaren Rahmenwerk. Die Web Content Accessibility Guidelines (WCAG) – aktuell in Version 2.1, mit wachsender Relevanz von WCAG 2.2 – definieren vier Grundprinzipien: wahrnehmbar, bedienbar, verständlich und robust. Jedes Prüfkriterium lässt sich einem dieser Prinzipien zuordnen. Die Konformitätsstufen A, AA und AAA bilden dabei eine Hierarchie: Stufe AA gilt als gesetzlicher Mindeststandard in den meisten europäischen Regulierungen. Für öffentliche Stellen sowie ab 2025 für viele privatwirtschaftliche Anbieter ist die Einhaltung dieser Stufe verpflichtend – mehr dazu erfahren Sie in unserem Beitrag BFSG: Was Unternehmen ab 2025 beachten müssen.

Ein einmaliger Audit reicht selten aus. Digitale Produkte ändern sich kontinuierlich – neue Funktionen, überarbeitete Designs, aktualisierte Inhalte. Empfehlenswert ist daher ein regelmäßiger Prüfzyklus: mindestens jährlich, bei agiler Entwicklung nach jedem größeren Release. Nur so bleibt der Accessibility-Status dauerhaft transparent und nachweisbar.

Die vier Prüfdimensionen: WCAG systematisch anwenden

Ein vollständiger Accessibility Test gliedert sich entlang der vier WCAG-Prinzipien. Das Prinzip der Wahrnehmbarkeit betrifft alle Inhalte, die Nutzerinnen und Nutzern präsentiert werden: Haben Bilder aussagekräftige Alternativtexte? Werden Videos mit Untertiteln versehen? Ist der Farbkontrast zwischen Text und Hintergrund ausreichend? WCAG 2.1 schreibt für normalen Text ein Kontrastverhältnis von mindestens 4,5:1 vor, für großen Text mindestens 3:1. Diese Werte sind keine Schätzung – sie lassen sich mit Werkzeugen wie dem WebAIM Contrast Checker exakt messen.

Das Prinzip der Bedienbarkeit stellt sicher, dass alle Funktionen ohne Maus zugänglich sind. Tastaturnavigation ist hierbei das Mindestmaß: Jeder interaktive Bereich – Links, Formulare, Dialoge, Karussells – muss per Tab-Taste erreichbar und per Enter oder Leertaste auslösbar sein. Der Fokusindikator muss dabei sichtbar bleiben; ein unsichtbarer Fokus ist einer der häufigsten und folgenreichsten Accessibility-Fehler überhaupt. Zeitbegrenzungen für Aktionen müssen anpassbar oder deaktivierbar sein, und Inhalte dürfen keine Elemente enthalten, die mehr als dreimal pro Sekunde blitzen – ein Schutz vor fotosensitiven Anfällen.

Unter Verständlichkeit fallen Sprachauszeichnung, Fehlermeldungen und vorhersehbares Verhalten. Das lang-Attribut im HTML-Dokument klingt trivial, ist aber für Screenreader essenziell: Fehlt es, liest die Sprachausgabe deutschen Text mit englischer Aussprache – mit entsprechend katastrophalem Ergebnis. Formulare müssen bei Fehleingaben klare, beschreibende Rückmeldungen geben, die nicht allein auf Farbe basieren. Das vierte Prinzip, Robustheit, prüft die technische Kompatibilität: Valides HTML, korrekt eingesetzte ARIA-Attribute und die Kompatibilität mit assistiven Technologien stehen im Mittelpunkt.

Accessibility Test Checkliste: Schritt für Schritt durch den Audit

Die folgende Checkliste orientiert sich an den WCAG-2.1-Erfolgskriterien auf Stufe AA und ist sowohl für Websites als auch für native und webbasierte Apps anwendbar. Sie ersetzt keine vollständige Prüfung durch zertifizierte Accessibility-Expertinnen und -Experten, bietet aber eine solide Grundlage für interne Vorabprüfungen und kontinuierliches Monitoring.

1. Alternativtexte prüfen: Alle informationstragenden Bilder, Icons und Grafiken haben sinnvolle Alt-Attribute. Dekorative Bilder erhalten alt="".
2. Farbkontraste messen: Text erfüllt das Kontrastverhältnis 4,5:1 (normal) bzw. 3:1 (groß, ab 18 pt oder 14 pt fett). Interaktive Komponenten erfüllen mindestens 3:1 gegen angrenzende Farben.
3. Tastaturnavigation testen: Alle Interaktionselemente sind per Tastatur erreichbar. Die Tab-Reihenfolge folgt dem visuellen Layout. Der Fokus ist jederzeit sichtbar.
4. Formularfelder beschriften: Jedes Eingabefeld hat ein programmatisch verknüpftes <label>. Pflichtfelder sind gekennzeichnet. Fehlermeldungen sind aussagekräftig und erscheinen in Texform.
5. Überschriftenhierarchie kontrollieren: Überschriften sind semantisch korrekt gegliedert (H1 → H2 → H3). Keine Überschriftenebene wird übersprungen.
6. Dokumentsprache auszeichnen: Das lang-Attribut ist im <html>-Element gesetzt. Fremdsprachige Passagen erhalten eigene Sprachattribute.
7. Videos und Audioinhalte prüfen: Voraufgezeichnete Videos haben Untertitel und eine Audiodeskription. Audioinhalte besitzen ein Texttranskript.
8. Resize-Test durchführen: Inhalte sind bei 200 % Zoomstufe ohne horizontales Scrollen nutzbar. Text skaliert ohne Informationsverlust.
9. ARIA-Verwendung validieren: ARIA-Rollen und -Attribute sind semantisch korrekt eingesetzt. ARIA ersetzt valides HTML nicht, sondern ergänzt es.
10. Zeitbegrenzungen dokumentieren: Sessions mit Zeitlimit bieten mindestens eine Option zum Verlängern oder Deaktivieren. Ausnahmen sind dokumentiert.
11. Bewegungen und Animationen: Animierte Inhalte können pausiert werden. Das prefers-reduced-motion-Media-Feature wird respektiert.
12. Touch-Targets für Apps: Interaktive Elemente in mobilen Apps haben eine Mindestgröße von 44 × 44 CSS-Pixeln (Apple-Richtlinie) bzw. 48 × 48 dp (Google Material).

Ergänzend sollte bei nativen Apps geprüft werden, ob plattformspezifische Accessibility-APIs korrekt genutzt werden. iOS verwendet UIAccessibility, Android das Accessibility-Framework mit TalkBack-Unterstützung. Wer testen möchte, wie Screenreader die eigene Anwendung vorlesen, findet in unserem Vergleich Screenreader im Vergleich: JAWS, NVDA und VoiceOver eine detaillierte Entscheidungshilfe für die Auswahl geeigneter Testwerkzeuge.

Automatisierte Tools versus manuelle Prüfung: Was leisten sie wirklich?

Automatisierte Accessibility-Scanner wie axe, Lighthouse, WAVE oder Deque's axe DevTools sind schnell, reproduzierbar und gut in CI/CD-Pipelines integrierbar. Sie sind jedoch kein Ersatz für manuelle Prüfung. Studien – darunter die vielzitierte WebAIM Million Report Analyse – belegen konsistent, dass automatisierte Tools nur etwa 30 bis 40 Prozent aller WCAG-Verstöße aufdecken. Fehlende Alternativtexte, doppelte IDs oder fehlende Formular-Labels finden Scanner zuverlässig. Ob ein vorhandener Alternativtext tatsächlich sinnvoll ist, ob die Lesereihenfolge logisch wirkt oder ob eine Fehlermeldung verständlich formuliert wurde – das beurteilt kein Algorithmus.

„Automatisierung findet die Symptome. Menschen finden die Ursachen." – Leitsatz aus der Accessibility-Praxis, der den komplementären Charakter beider Methoden treffend beschreibt.

Die manuelle Prüfung umfasst drei wesentliche Komponenten: erstens die Expertenprüfung, bei der geschulte Prüferinnen und Prüfer jeden Prüfpunkt systematisch durcharbeiten; zweitens den Screenreader-Test mit mindestens zwei verschiedenen Kombinationen aus Screenreader und Browser (z. B. NVDA mit Firefox, JAWS mit Chrome, VoiceOver mit Safari); und drittens den Nutzbarkeitstest mit betroffenen Personen, der als einzige Methode die tatsächliche Alltagstauglichkeit validiert. Gerade dieser letzte Schritt wird in der Praxis häufig aus Zeit- oder Budgetgründen weggelassen – dabei liefert er oft die aufschlussreichsten Erkenntnisse.

Ein pragmatischer Ansatz kombiniert beide Methoden: Automatisierte Scans laufen bei jedem Build automatisch und verhindern Regressionen. Manuelle Experten-Audits finden ein- bis zweimal jährlich statt und decken komplexere Barrieren auf. Nutzertests mit Menschen mit Behinderungen werden idealerweise in User-Research-Zyklen integriert und ergänzen das Bild mit qualitativen Erkenntnissen.

Typische Fehler und wie Sie sie vermeiden

Manche Accessibility-Probleme treten mit bemerkenswerter Regelmäßigkeit auf – unabhängig von Branche, Technologie oder Teamgröße. Die WebAIM Million-Studie analysiert jährlich die Startseiten von einer Million Websites und findet dabei seit Jahren dieselben Spitzenreiter unter den Barrieren. Zu kennen, wo die häufigsten Stolpersteine liegen, ist der erste Schritt zur Vermeidung.

• Fehlende Alternativtexte: Betrifft laut WebAIM rund 55 % aller geprüften Seiten. Besonders häufig bei automatisch eingefügten CMS-Bildern ohne redaktionelle Pflege.
• Unzureichende Farbkontraste: Beliebt in modernen Flat-Design-Trends mit hellgrauen Texten auf weißen Hintergründen. Betrifft etwa 83 % der analysierten Startseiten.
• Fehlende Formular-Labels: Placeholder-Texte in Eingabefeldern verschwinden beim Tippen und ersetzen kein echtes Label – ein häufiger Irrtum in UI-Bibliotheken.
• Leere Linktexte: „Hier klicken" oder Icon-Links ohne Beschriftung sagen Screenreader-Nutzerinnen und -Nutzern nichts über das Ziel aus.
• Fehlende Sprachauszeichnung: Das lang-Attribut fehlt auf erschreckend vielen Seiten, obwohl die Korrektur weniger als eine Minute beansprucht.
• Nicht tastaturzugängliche Modaldialoge: Fokus wird beim Öffnen nicht in das Modal versetzt, beim Schließen nicht zurückgeführt – ein klassischer Fokus-Trap-Fehler.

Viele dieser Fehler entstehen nicht aus Gleichgültigkeit, sondern aus fehlendem Wissen. Ein strukturierter Audit hilft, blinde Flecken im Team zu identifizieren und Accessibility-Kompetenz gezielt aufzubauen. Wichtig ist dabei: Ein Audit-Ergebnis sollte nie als Vorwurf, sondern als Lernchance kommuniziert werden. Nur so entsteht die interne Bereitschaft, Barrierefreiheit als dauerhafte Qualitätsdimension zu verankern – und nicht als lästige Compliance-Pflicht.

Audit-Ergebnisse dokumentieren und priorisieren

Ein Audit ohne strukturierten Bericht bleibt wirkungslos. Die Dokumentation der Prüfergebnisse sollte mindestens folgende Elemente enthalten: das geprüfte WCAG-Kriterium mit Versionsnummer und Konformitätsstufe, eine Beschreibung des Befundes mit Screenshot oder Code-Ausschnitt, den betroffenen Seitenbereich oder die Komponente, den Schweregrad sowie eine konkrete Handlungsempfehlung. Ohne diese Informationen fehlt Entwicklerinnen und Entwicklern der direkte Anknüpfungspunkt für die Behebung.

Die Priorisierung von Befunden folgt idealerweise zwei Achsen: der Schwere der Barriere (blockt ein Fehler den vollständigen Zugang oder verursacht er nur Umwege?) und der Betroffenenquote (wie viele Nutzerinnen und Nutzer sind betroffen?). Ein fehlender Alternativtext auf dem Hauptlogo trifft potenziell alle Screenreader-Nutzer auf jeder einzelnen Seite – und hat damit eine weit höhere Priorität als ein marginaler Kontrast-Fehler im Footer-Kleingedruckten.

Für die praktische Umsetzung empfiehlt sich eine dreistufige Priorisierung: Kritisch (vollständige Zugangssperre, sofortige Behebung erforderlich), Wichtig (erhebliche Erschwernis, Behebung im nächsten Sprint) und Empfohlen (verbesserungswürdig, Behebung im Rahmen regulärer Entwicklung). Diese Kategorisierung macht Audit-Ergebnisse für Product Owner und Entwicklungsteams direkt handlungsleitend und verhindert, dass der Bericht in einer Schublade verschwindet.

Abschließend gilt: Ein Barrierefreiheits-Audit ist kein Projekt mit einem definierten Ende, sondern ein fortlaufender Prozess. Die Integration von Accessibility-Tests in den regulären Entwicklungsworkflow – durch automatisierte Checks, geschulte Entwicklerinnen und Entwickler sowie klare Definition-of-Done-Kriterien – ist langfristig effektiver als periodische Großprüfungen. Wer Barrierefreiheit von Anfang an mitdenkt, spart Zeit, Kosten und vermeidet rechtliche Risiken.