Was ist ein Accessibility Audit? So prüfen Sie, ob Ihre Website WCAG-konform ist

Laut dem neuesten WebAIM Million Report wurden 56 Millionen unterschiedliche Barrierefreiheitsfehler auf einer Million Startseiten festgestellt – im Durchschnitt 56 Fehler pro Seite. Das bedeutet, dass die überwältigende Mehrheit der Websites Nutzer mit Behinderungen jeden einzelnen Tag aktiv im Stich lässt. Wenn Sie Website-Betreiber, Entwickler oder Compliance-Manager sind und sich fragen, ob Ihre Seite WCAG-konform ist, führt die Antwort fast zwangsläufig über ein gründliches Barrierefreiheitsaudit. Die Frage ist: Was bedeutet das konkret, und wie macht man es richtig?

Warum Barrierefreiheitsaudits unverzichtbar geworden sind

Web-Barrierefreiheit ist längst über den Bereich guter Absichten hinaus. Sie ist inzwischen in einer wachsenden Zahl von Rechtsordnungen eine gesetzliche Pflicht, und die Folgen von Nicht-Compliance sind konkret und messbar. Über 4.000 Klagen wegen mangelnder Web-Barrierefreiheit wurden 2024 in den USA eingereicht, und der Trend steigt weiter. Gerichte in den USA haben wiederholt entschieden, dass Websites von Unternehmen, die der Öffentlichkeit zugänglich sind, gemäß ADA Title III barrierefrei sein müssen. Gleichzeitig ist der European Accessibility Act seit Juni 2025 in allen EU-Mitgliedstaaten durchsetzbar und erweitert die Anforderungen über Regierungsseiten hinaus auf Banking-Apps, E‑Commerce-Plattformen, SaaS-Produkte und mehr.

Die Zahlen zeichnen ein klares Bild. Rund 16% der Weltbevölkerung – etwa 1,3 Milliarden Menschen – leben mit irgendeiner Form von Behinderung. Allein in den USA hat ungefähr jeder vierte Erwachsene eine Behinderung. Das sind keine Randnutzer. Es sind Kunden, Mitarbeitende, Studierende und Bürger, die auf Websites auf Barrieren stoßen, an die die meisten Entwickler nie denken.

Über das rechtliche Risiko hinaus gibt es einen messbaren Business Case. Barrierefreie Websites schneiden in Suchmaschinen besser ab, weil dieselbe strukturelle Klarheit, die Screenreadern hilft – semantische Überschriften, beschreibender Alt-Text, sauberes Markup – auch Crawlern hilft. Inklusives Design verbessert die Nutzbarkeit für alle: Untertitel helfen Menschen in lauten Umgebungen, hoher Kontrast hilft Menschen bei hellem Sonnenlicht, und Tastaturnavigation kommt Power-Usern zugute. Ein Barrierefreiheitsaudit ist der erste Schritt, um all diese Vorteile zu erschließen.

Ein weiterer wichtiger Wandel: ADA Title II verlangt nun ausdrücklich Web-Barrierefreiheit für staatliche und kommunale Einrichtungen in den USA, wobei das DOJ WCAG 2.1 Level AA als technischen Standard übernommen hat. Einrichtungen, die Bevölkerungen von 50.000 oder mehr bedienen, haben eine Compliance-Frist bis zum 26. April 2026. Wenn Sie mit Kunden aus dem öffentlichen Sektor arbeiten oder in regulierten Branchen tätig sind, ist ein Audit nicht mehr optional – es ist dringend.

Was genau ist ein WCAG-Barrierefreiheitsaudit?

Ein Web-Barrierefreiheitsaudit ist eine systematische Bewertung der Konformität Ihrer Website mit den Web Content Accessibility Guidelines (WCAG) – dem international anerkannten technischen Standard für digitale Barrierefreiheit, entwickelt vom W3C. In der Praxis identifiziert ein Audit konkrete Barrieren, die Nutzer mit Behinderungen daran hindern, Ihre Inhalte wahrzunehmen, zu verstehen, zu navigieren und mit ihnen zu interagieren. Es ordnet diese Barrieren den WCAG-Erfolgskriterien zu, weist Schweregrade zu und erstellt eine Roadmap für die Behebung.

WCAG liegt derzeit in Version 2.2 vor, veröffentlicht Ende 2023 und im Mai 2025 vom W3C formell als höchster Standard für Web-Barrierefreiheit bestätigt. Sie umfasst neun neue Erfolgskriterien gegenüber WCAG 2.1, die Bereiche wie Sichtbarkeit des Tastaturfokus, minimale Touch-Zielgrößen, Alternativen zu Drag-Bewegungen und konsistente Hilfemechanismen abdecken. Wichtig ist, dass WCAG 2.2 abwärtskompatibel ist – wer 2.2 erfüllt, erfüllt auch 2.1 und 2.0.

WCAG ist in drei Konformitätsstufen organisiert. Level A deckt die kritischsten Barrieren ab – Fehler auf dieser Stufe machen Inhalte für einige Nutzer vollständig unbenutzbar. Level AA ist das Ziel, das von den meisten Barrierefreiheitsgesetzen weltweit vorgeschrieben wird, einschließlich ADA, European Accessibility Act und Section 508. Level AAA stellt die höchste Hürde dar und ist typischerweise eher ein Anspruch als eine gesetzliche Pflicht. Wenn jemand sagt, seine Seite sei „WCAG-konform“, ist fast immer WCAG 2.1 oder 2.2, Level AA gemeint.

WCAG basiert auf vier Kernprinzipien, die oft mit dem Akronym POUR zusammengefasst werden: Inhalte müssen Perceivable (wahrnehmbar), Operable (bedienbar), Understandable (verständlich) und Robust (robust) sein. Jedes Erfolgskriterium lässt sich einem dieser vier Prinzipien zuordnen, und ein gründliches Audit prüft die Konformität mit allen.

Die häufigsten Fehler, die Audits aufdecken

Etwa 96% aller festgestellten Barrierefreiheitsfehler fallen in nur sechs Kategorien. Zu wissen, wonach man suchen muss, ist der schnellste Weg, den Auditaufwand zu priorisieren:

• Text mit geringem Kontrast. Dies ist durchgängig der häufigste Fehler. Fast 84% der Startseiten enthalten Text, der unter dem WCAG 2 AA-Kontrastschwellenwert von 4,5:1 für normalen Text liegt. Auditoren prüfen die Farbkontrastverhältnisse zwischen Vorder- und Hintergrund mit Tools wie dem TPGi Colour Contrast Analyser.
• Fehlender Alternativtext. Über 16% aller Bilder auf Startseiten haben kein Alt-Attribut, sodass Screenreader-Nutzer keine Möglichkeit haben, den Bildinhalt zu verstehen. Verlinkte Bilder ohne Alt-Text sind besonders problematisch – sie werden zu bedeutungslosen Navigationselementen.
• Leere Links. Links ohne sichtbaren Text und ohne zugänglichen Namen erzeugen Sackgassen für Tastatur- und Screenreader-Nutzer, die nicht erkennen können, wohin der Link führt.
• Fehlende Formularfeld-Beschriftungen. Formulare ohne programmatisch verknüpfte Labels sind für Screenreader-Nutzer unbenutzbar. Das betrifft sowohl sichtbare Labels als auch versteckte Labels mit aria-label oder aria-labelledby.
• Leere Buttons. Nur aus Icons bestehende Buttons ohne zugänglichen Namen – häufig in Navigationen und Slidern – lassen nicht-visuelle Nutzer im Unklaren darüber, was der Button bewirkt.
• Fehlende Dokumentensprache. Das lang-Attribut am <html>-Element teilt Screenreadern mit, welche Sprache verwendet werden soll. Fehlt es, führt das zu falscher Aussprache und Desorientierung bei Nutzern, die auf Text-to-Speech angewiesen sind.

Audits zeigen immer wieder, dass die schädlichsten Fehler auch die am einfachsten zu behebenden sind. Geringer Kontrast, fehlender Alt-Text und nicht beschriftete Formularfelder lassen sich oft in Tagen statt in Monaten beheben.

Über diese sechs hinaus deckt ein gründliches Audit auch fehlende Skip-Links zur Navigation (die Tastaturnutzer zwingen, auf jeder Seite durch jedes Kopfzeilenelement zu tabben), eine fehlerhafte Überschriftenhierarchie, unzugängliche Modale und Dialoge mit falsch gesteuertem Fokus, Videos ohne Untertitel, PDFs ohne getaggte Struktur und benutzerdefinierte JavaScript-Widgets auf, die keine zugänglichen Rollen und Zustände über ARIA bereitstellen.

Wie man ein Barrierefreiheitsaudit durchführt: Schritt für Schritt

Ein ordentliches Barrierefreiheitsaudit ist kein einzelner Scan – es ist ein mehrstufiger Prozess, der automatisierte Tools mit fachkundigem menschlichem Urteil kombiniert. So gehen Sie systematisch vor:

Schritt 1: Umfang definieren

Bevor Sie einen einzigen Test ausführen, legen Sie fest, was Sie prüfen. Bei einer großen Website ist es unpraktisch, jede Seite zu testen. Wenden Sie stattdessen den vom W3C entwickelten WCAG-EM-Ansatz (Website Accessibility Conformance Evaluation Methodology) an: Definieren Sie eine repräsentative Stichprobe, die alle einzigartigen Seitentemplates, alle wichtigen User Journeys und alle unterschiedlichen Inhaltstypen abdeckt. Eine Stichprobe für eine E‑Commerce-Site könnte die Startseite, eine Kategorieseite, eine Produktdetailseite, den Warenkorb, den Checkout-Prozess, den Konto-Login, ein Kontaktformular und einen Blogbeitrag umfassen. Stellen Sie sicher, dass dynamische Zustände enthalten sind – geöffnete Menüs, Fehlermeldungen in Formularen, Modaldialoge und geladene Suchergebnisse müssen alle bewertet werden.

Schritt 2: Automatisierte Scans durchführen

Automatisierte Tools sind die Grundlage jedes effizienten Audits. Sie scannen Ihr HTML schnell, markieren eindeutige Regelverstöße und liefern eine Basisliste von Problemen. Wichtige Tools sind:

• axe DevTools (Browser-Erweiterung oder CLI) – weit verbreitet, geringe False-Positive-Rate, Integration in CI/CD-Pipelines
• WAVE (WebAIM) – annotiert Seiten visuell mit Fehler-Icons und macht sie so für nicht-technische Teammitglieder intuitiv nachvollziehbar
• Lighthouse (in Chrome DevTools integriert) – liefert einen Accessibility-Score neben Performance- und SEO-Metriken
• Colour Contrast Analyser (TPGi) – wählt beliebige Farben auf dem Bildschirm aus und prüft sie gegen WCAG-Schwellenwerte
• PAC 2024 – spezieller PDF-Barrierefreiheitschecker für herunterladbare Dokumente

Eine entscheidende Einschränkung: Automatisierte Tools können nur zwischen 30% und 40% der WCAG-Probleme erkennen. Sie sind hervorragend darin, regelbasierte Fehler wie fehlende Attribute, ungültige ARIA-Rollen und Kontrastverhältnisse zu markieren. Aber sie können nicht beurteilen, ob Alt-Text aussagekräftig ist, ob ein Formular logisch aufgebaut ist oder ob ein Nutzer eine Aufgabe tatsächlich abschließen kann. Deshalb ist Automatisierung Schritt 2 und nicht das gesamte Audit.

Schritt 3: Manuelle Expertenprüfung

Die manuelle Prüfung durch eine sachkundige Person – idealerweise ein Team – bestimmt die Tiefe eines Audits. Dazu gehören:

• Navigation nur mit Tastatur. Ziehen Sie die Maus ab und versuchen Sie, jede zentrale User Journey nur mit Tab, Shift+Tab, Enter, Leertaste und Pfeiltasten zu durchlaufen. Können Sie jedes interaktive Element erreichen? Ist der Fokusindikator immer sichtbar? Verschwindet der Fokus irgendwann in einer Komponente?
• Screenreader-Tests. Verwenden Sie NVDA mit Chrome oder Firefox unter Windows und VoiceOver mit Safari unter macOS und iOS. Navigieren Sie über Überschriften, Landmarken, Links und Formulare. Ergibt die Seite ohne visuelle Kontexte Sinn? Werden alle interaktiven Elemente korrekt angekündigt?
• Visuelle und kognitive Prüfung. Überprüfen Sie die Überschriftenhierarchie auf logische Struktur, stellen Sie sicher, dass Fehlermeldungen aussagekräftig sind und dem richtigen Feld zugeordnet werden, vergewissern Sie sich, dass zeitbasierte Medien Untertitel und Transkripte haben, und prüfen Sie, dass Anweisungen sich nicht ausschließlich auf Farbe, Form oder Position stützen.
• Code-Inspektion. Prüfen Sie HTML-Semantik, ARIA-Einsatz, Fokusmanagement in benutzerdefinierten Widgets und Landmark-Regionen. Ein Modal, das den Fokus nicht einfängt, oder eine ARIA-Live-Region, die bei jedem Tastendruck feuert, wird nur auf dieser Ebene entdeckt.

Schritt 4: Tests mit unterstützender Technologie und realen Nutzern

Der Goldstandard – und oft die aufschlussreichste Phase – ist das Testen mit tatsächlichen Nutzern, die täglich auf unterstützende Technologien angewiesen sind. Menschen, die Screenreader, Schaltzugangssysteme oder Sprachsteuerungssoftware nutzen, navigieren auf eine Weise, die selbst erfahrene manuelle Tester nicht vollständig nachbilden. Die Einbeziehung behinderter Nutzer in Ihre Bewertung bringt reale Reibungspunkte ans Licht, die Tools und Checklisten schlicht nicht vorhersehen können.

Schritt 5: Ergebnisse dokumentieren und priorisieren

Eine rohe Liste von Fehlern ist kein Auditbericht – sie ist ein Ausgangspunkt. Ein nützliches Auditdokument sollte Folgendes angeben: die betroffene URL oder Komponente, das verletzte WCAG-Erfolgskriterium, die Schwere (kritisch, hoch, mittel, niedrig), die Auswirkungen auf betroffene Nutzer und konkrete Hinweise zur Behebung mit Codebeispielen, wo sinnvoll. Die Priorität sollte in erster Linie nach Nutzerimpact vergeben werden, nicht nach technischer Bequemlichkeit. Ein defektes Formularlabel, das den Checkout verhindert, ist dringender als eine suboptimale Überschriftenebene in einer Blog-Seitenleiste.

Schritt 6: Beheben, validieren und überwachen

Sobald Korrekturen umgesetzt sind, validieren Sie sie – gehen Sie nicht davon aus, dass die Behebung funktioniert hat. Testen Sie jede Korrektur mit derselben Kombination aus Tools und manuellen Checks, die Sie im ursprünglichen Audit verwendet haben. Nachdem Sie ein grundlegendes Konformitätsniveau erreicht haben, richten Sie eine kontinuierliche Überwachung ein. Neue Inhalte, CMS-Updates und Drittanbieter-Skripte können jederzeit Regressionen einführen. Behandeln Sie Barrierefreiheit wie Sicherheit: etwas, das Sie pflegen, nicht etwas, das Sie einmal erreichen und dann vergessen.

Automatisierte Scans vs. vollständige Audits: den Unterschied verstehen

Dieser Unterschied ist enorm wichtig, insbesondere im rechtlichen Kontext. Ein automatisierter Scan führt eine regelbasierte Prüfung Ihres gerenderten HTML durch. Er dauert Sekunden oder Minuten und liefert eine Liste erkannter Verstöße. Er ist hervorragend geeignet, um offensichtliche, häufig auftretende Probleme zu erkennen und um in CI/CD-Workflows integriert zu werden, damit neue Regressionen nicht ausgeliefert werden. Viele Overlay- und Widget-Produkte – einschließlich Barrierefreiheits-Tools – bieten automatisierte Scanning-Dashboards als Teil ihres Funktionsumfangs an, und diese sind für die laufende Überwachung tatsächlich nützlich.

Ein vollständiges Audit hingegen bewertet Ihre Site anhand jedes anwendbaren WCAG-Erfolgskriteriums mit einer Kombination aus automatisiertem Scanning, manueller Expertenprüfung, Screenreader-Tests und Navigation nur mit Tastatur. Ein umfassendes Audit, das automatisierte und manuelle Methoden kombiniert, kann über 90% der Barrierefreiheitsprobleme aufdecken, verglichen mit der 30–40%-Obergrenze der reinen Automatisierung. Wenn Sie mit einem rechtlichen Aufforderungsschreiben, einer Beschaffungsanforderung oder einer regulatorischen Anfrage konfrontiert sind, liefert nur ein vollständiges Audit die Dokumentation, die Sie benötigen.

Viele Organisationen nutzen eine praktische Hybridstrategie: Automatisierte Scans laufen kontinuierlich in CI/CD, um Regressionen früh zu erkennen, während ein vollständiges manuelles Audit jährlich oder nach größeren Site-Redesigns durchgeführt wird. Das balanciert Gründlichkeit und Effizienz und hält die Compliance langfristig handhabbar.

Kein Tool allein kann bestimmen, ob eine Site Barrierefreiheitsstandards erfüllt. Eine sachkundige menschliche Bewertung ist erforderlich, um festzustellen, ob eine Site wirklich barrierefrei ist. — W3C Web Accessibility Initiative

Was tun mit den Auditergebnissen: Planung der Behebung

Ein abgeschlossenes Audit ist nur dann wertvoll, wenn es zu Maßnahmen führt. Wie Sie die Behebungsarbeiten priorisieren, ist genauso wichtig wie die Identifizierung der Probleme. Ein praktischer Rahmen für die Priorisierung der Behebung sieht so aus:

1. Kritisch (sofort beheben): Probleme, die Nutzer vollständig daran hindern, zentrale Aufgaben zu erledigen – ein defektes Checkout-Formular, ein unzugängliches Login-Modal, ein Navigationsmenü, das mit der Tastatur nicht erreichbar ist. Sie stellen das höchste rechtliche Risiko und die größten Auswirkungen auf Nutzer dar.
2. Hoch (innerhalb des aktuellen Sprints oder Release-Zyklus beheben): Probleme, die die Nutzbarkeit für behinderte Nutzer erheblich beeinträchtigen, sie aber nicht vollständig blockieren – fehlender Alt-Text bei Produktbildern, geringer Kontrast im Fließtext, nicht beschriftete Icon-Buttons in der gesamten Oberfläche.
3. Mittel (geplante Behebung): Probleme, die Reibung verursachen, aber Workarounds haben – inkonsistente Fokusindikatoren, fehlende Skip-Links, suboptimale Überschriftenhierarchie.
4. Niedrig (Backlog mit definiertem Verantwortlichen): Probleme, die Best-Practice-Verbesserungen darstellen, aber in den meisten Fällen die Nutzbarkeit wahrscheinlich nicht beeinträchtigen – AAA-Verbesserungen, kleinere ARIA-Verbesserungen in Bezug auf Verbosität.

Dokumentieren Sie Ihren Behebungsplan und Zeitplan, auch wenn noch nicht alle Korrekturen abgeschlossen sind. Aufsichtsbehörden und Gerichte bewerten nachweisliche, laufende, gutgläubige Verbesserungen in der Regel positiver als Untätigkeit. Wenn Sie ein Aufforderungsschreiben erhalten, sind ein Auditbericht plus ein Behebungsplan eine deutlich stärkere Position als gar keine Dokumentation.

Overlay-Widgets und SDK-Tools – wie das von Accsible angebotene – können in der Behebungsphase eine sinnvolle Rolle spielen. Sie können sofortige Korrekturen für einen erheblichen Teil häufiger Probleme bereitstellen (insbesondere visuelle Präferenzen wie Kontrast, Schriftgröße und Abstände), während Ihr Entwicklungsteam an tiefergehenden Code-Anpassungen arbeitet. Entscheidend ist, zu verstehen, was Overlays gut lösen, und sie als Teil einer gestuften Strategie zu nutzen, nicht als Ersatz für Code-Korrekturen bei kritischen Barrieren.

Wie oft sollten Sie ein Barrierefreiheitsaudit durchführen?

Ein einmaliges Audit ist eine Momentaufnahme Ihrer Site an einem bestimmten Tag. Websites sind lebende Produkte – Inhalte ändern sich, Drittanbieter-Skripte werden aktualisiert, Komponenten werden ersetzt und neue Features ausgeliefert. Jeder dieser Vorgänge kann neue Barrieren einführen. Ein nachhaltiges Barrierefreiheitsprogramm sieht typischerweise so aus:

• Kontinuierliches automatisiertes Scanning, integriert in Ihre CI/CD-Pipeline oder über ein Monitoring-Dashboard, um Regressionen zu erkennen, bevor sie in die Produktion gelangen
• Vierteljährliche manuelle Stichprobenprüfungen auf Seiten mit hohem Traffic und hohem Risiko (Checkout, Login, Kontaktformulare, wichtige Landingpages)
• Jährliches vollständiges Audit, durchgeführt von qualifizierten Barrierefreiheitsexperten, insbesondere nach größeren Redesigns oder Plattformmigrationen
• Audit in der Designphase für jedes neue große Feature oder Redesign – Barrierefreiheit ist deutlich günstiger einzubauen als nachträglich zu ergänzen

Der kosteneffektivste Ansatz besteht darin, Barrierefreiheit nach links zu verlagern – sie von Anfang an in den Design- und Entwicklungsprozess zu integrieren, statt sie als Compliance-Übung nach dem Launch zu behandeln. Entwickler, die die WCAG-Anforderungen verstehen, erkennen Probleme an der Quelle. Designer, die über Farbkontrast und Touch-Zielgrößen Bescheid wissen, treffen standardmäßig barrierefreie Entscheidungen. Ein Audit wird dann zu einer Qualitätskontrolle statt zu einem Notfalleinsatz.

Wesentliche Erkenntnisse

• Die meisten Websites verfehlen WCAG. Über 95% der Startseiten weisen erkennbare Barrierefreiheitsfehler auf, und die sechs häufigsten Fehler – geringer Kontrast, fehlender Alt-Text, leere Links, fehlende Formularlabels, leere Buttons und fehlende Dokumentensprache – machen den Großteil aus. All dies ist behebbar.
• Automatisierte Tools sind notwendig, aber nicht ausreichend. Automatisierte Scanner erfassen bestenfalls 30–40% der WCAG-Probleme. Ein vollständiges Audit erfordert Tastaturtests, Screenreader-Tests und eine fachkundige menschliche Überprüfung von Code und UX-Flows.
• WCAG 2.2 Level AA ist das Ziel. Es ist der Standard, auf den sich ADA, European Accessibility Act, Section 508 und die meisten anderen Barrierefreiheitsrahmen weltweit beziehen. Wer 2.2 AA anstrebt, deckt automatisch alle niedrigeren Versionen ab.
• Behebung braucht einen Priorisierungsrahmen. Beginnen Sie mit Problemen, die zentrale User Journeys vollständig blockieren, und arbeiten Sie sich dann durch häufige, stark wirkende Probleme. Dokumentieren Sie alles – Ihr Auditbericht und Ihr Behebungsplan sind Ihre beste rechtliche Absicherung.
• Barrierefreiheit ist fortlaufend, nicht einmalig. Kombinieren Sie kontinuierliches automatisiertes Monitoring mit regelmäßigen manuellen Audits und verlagern Sie Barrierefreiheit von Anfang an in Ihren Design- und Entwicklungsprozess. Ein Overlay-Widget wie Accsible kann Lücken überbrücken, während tiefgreifendere Behebungen im Gange sind.