Hier ist eine unbequeme Wahrheit: 94,8 % der Top-Eine-Million-Websites bestehen grundlegende Barrierefreiheitsprüfungen nicht, laut dem WebAIM Million Report 2025. Diese Zahl hat sich in fünf Jahren kaum verändert, trotz wachsendem Bewusstsein, neuen Gesetzen und einer Flut automatisierter Tools, die versprechen, alles zu beheben. Was läuft also schief? Meistens überspringen die Leute die schwierigen Teile. Sie lassen einen automatisierten Scan laufen, beheben ein paar Farbkontrast-Probleme und erklären die Arbeit für erledigt. Aber automatisierte Tools erkennen nur 30 % bis 57 % der WCAG-Verstöße. Der Rest erfordert, dass ein Mensch sich hinsetzt, die Maus weglegt, einen Screenreader startet und die Website tatsächlich benutzt. Mit dem seit Juni 2025 durchgesetzten European Accessibility Act, den digitalen ADA-Title-II-Anforderungen ab April 2026 und über 5.100 Barrierefreiheitsklagen allein im Jahr 2025 waren die Einsätze noch nie höher. Dieser Leitfaden führt Sie durch einen vollständigen Audit-Prozess in acht konkreten Schritten. Kein Ballast, keine theoretischen Frameworks, die Sie nie verwenden werden. Nur praktische Techniken, die echte Probleme auf echten Websites finden.
Was genau ist ein Web-Accessibility-Audit?
Ein Web-Accessibility-Audit ist eine strukturierte Bewertung einer Website anhand etablierter Barrierefreiheitsstandards, hauptsächlich der Web Content Accessibility Guidelines (WCAG). Das Ziel ist einfach: Jede Barriere identifizieren, die Menschen mit Behinderungen daran hindert, Ihre Website wahrzunehmen, zu verstehen, zu navigieren und mit ihr zu interagieren.
Stellen Sie es sich wie eine Gebäudeinspektion vor, aber für Ihr digitales Eigentum. Ein Inspektor prüft Rampen, Aufzugknöpfe, Türbreiten und Beschilderung. Ein Accessibility-Auditor prüft Tastaturnavigation, Screenreader-Kompatibilität, Farbkontrast, Formularbeschriftungen und Dutzende weiterer Kriterien.
Es gibt drei Arten von Accessibility-Audits, und den Unterschied zu kennen ist wichtig, da er Ihre Erwartungen und Ihr Budget bestimmt.
Drei Arten von Audits
Die erste Art ist ein rein automatisiertes Audit. Sie lassen ein Tool wie axe, WAVE, Lighthouse oder web-accessibility-checker.com über Ihre Seiten laufen und erhalten einen Bericht maschinenerkennbarer Probleme. Das ist schnell und günstig, erkennt aber je nach Studie nur 30 % bis 57 % der WCAG-Verstöße. Fehlender Alt-Text? Automatisierte Tools finden ihn sofort. Schlechter Alt-Text, der "image123.jpg" statt einer Inhaltsbeschreibung sagt? Keine Ahnung. Die zweite Art ist ein manuelles Audit durch Barrierefreiheitsspezialisten. Sie navigieren mit der Tastatur, testen mit Screenreadern, bewerten die Inhaltsqualität und prüfen Interaktionen, die kein Algorithmus beurteilen kann. Das findet die übrigen 43 % bis 70 % der Probleme, erfordert aber geschultes Personal und erheblichen Zeitaufwand. Die dritte Art, und die, die Sie anstreben sollten, ist ein Hybrid-Audit, das beide Ansätze kombiniert. Beginnen Sie mit automatisiertem Scanning, um die offensichtlichen Verstöße im großen Maßstab zu erfassen, und ergänzen Sie dann manuelle Tests für die nuancierten Probleme. Genau das werden wir Schritt für Schritt durchgehen. Für eine schnelle Referenzversion zum Ausdrucken sehen Sie unsere Checkliste für Barrierefreiheits-Audits.Schritt 1: Audit-Umfang definieren
Bevor Sie ein Tool anfassen, müssen Sie drei Fragen beantworten. Welche Seiten werden Sie testen? Welchen Standard verwenden Sie als Maßstab? Und wie groß ist Ihre Stichprobe? Für den Standard ist WCAG 2.1 Level AA die Baseline, auf die sich praktisch jedes Barrierefreiheitsgesetz bezieht. Der European Accessibility Act schreibt ihn vor. ADA-Klagen beziehen sich darauf. Wenn Sie gerade anfangen, streben Sie WCAG 2.1 AA an. Wenn Sie weiter gehen möchten, hat WCAG 2.2 im Oktober 2023 neun neue Erfolgskriterien hinzugefügt, darunter Anforderungen an Focus-Darstellung, Ziehbewegungen und konsistente Hilfe-Platzierung. Unser WCAG-Leitfaden erläutert die Unterschiede im Detail. Bei der Seitenauswahl versuchen Sie nicht, jede einzelne Seite einer großen Website zu auditieren. Wählen Sie stattdessen eine repräsentative Stichprobe, die jedes einzigartige Template und jeden kritischen Nutzerpfad abdeckt. Das bedeutet typischerweise: die Startseite, Hauptnavigationsseiten, mindestens eine Seite jedes Inhaltstyps (Artikel, Produkt, Listing, Formular), den kompletten Checkout- oder Konversionsprozess, Login- und Kontoseiten, Suchergebnisse, Fehlerseiten und jede Seite mit komplexen interaktiven Komponenten wie Modals, Karussells oder Datentabellen. Für eine Website mit unter 50 Seiten auditieren Sie alles. Für größere Seiten erfasst eine Stichprobe von 20 bis 40 Seiten in der Regel alle einzigartigen Muster. Die entscheidende Erkenntnis ist, dass die Korrektur eines Templates jede Seite korrigiert, die dieses Template verwendet, wodurch Sie einen Kaskadeneffekt erzielen, wenn Sie sich auf Templates statt auf einzelne Seiten konzentrieren.Schritt 2: Automatisierten Scan durchführen
Beginnen Sie Ihr Audit mit automatisierten Tools, da sie sofortige, quantifizierbare Ergebnisse über viele Seiten liefern. Betrachten Sie dies als Triage: Sie identifizieren die offensichtlichsten Probleme, bevor Sie tiefer eintauchen. Lassen Sie Ihre Website durch web-accessibility-checker.com laufen, um einen schnellen Ausgangswert zu erhalten. Der kostenlose Scan prüft Ihre Seite gegen WCAG-Kriterien in unter einer Sekunde für DOM-basierte Probleme, mit einer tieferen Analyse im Anschluss. Sie erhalten eine Aufschlüsselung nach Schweregrad und WCAG-Prinzip, die Ihnen hilft, den Umfang der bevorstehenden Arbeit zu verstehen. Gleichen Sie dann mit mindestens einem weiteren Tool ab. Jeder automatisierte Scanner verwendet leicht unterschiedliche Regelwerke und Heuristiken, sodass die Kombination zweier Tools mehr Probleme findet als jedes einzelne. Gute kostenlose Optionen sind WAVE (exzellent für visuelle Überlagerung von Problemen), axe DevTools (starke Browser-Erweiterung mit detaillierten Erklärungen) und Lighthouse (in Chrome integriert, gut für Barrierefreiheit plus Performance und SEO). Pa11y eignet sich gut für Kommandozeilen-Integration und CI/CD-Pipelines. Dokumentieren Sie jeden Befund in einer Tabelle oder einem Issue-Tracker. Für jedes Problem erfassen Sie die Seiten-URL, das verletzte WCAG-Erfolgskriterium, einen Screenshot oder Code-Ausschnitt, den Schweregrad und welches Tool es gemeldet hat. Diese Dokumentation wird das Rückgrat Ihres Maßnahmenplans. Eine Warnung: Hören Sie hier nicht auf. Ich habe zu viele Organisationen gesehen, die einen automatisierten Scan durchführen, alles beheben, was er findet, und sich für barrierefrei erklären. Das lässt mindestens 43 % der Probleme vollständig unbehandelt. Für einen tieferen Vergleich der Test-Tools sehen Sie unseren Leitfaden zu den besten Accessibility-Checker-Tools.Schritt 3: Manuelle Tastaturtests
Legen Sie Ihre Maus in eine Schublade. Im Ernst. In diesem Schritt navigieren Sie Ihre gesamte Stichprobe nur mit der Tastatur, und Sie werden überrascht sein, wie schnell die Dinge auf vielen Websites zusammenbrechen.
Hier sind die Tasten, die Sie brauchen: Tab bewegt vorwärts durch interaktive Elemente. Shift plus Tab bewegt rückwärts. Enter aktiviert Links und Buttons. Leertaste aktiviert Buttons, Checkboxen und Toggles. Escape schließt Modals und Dropdowns. Pfeiltasten navigieren innerhalb von Komponenten wie Menüs, Tabs, Radiogruppen und Schiebereglern.
Beginnen Sie auf der Startseite und drücken Sie wiederholt Tab. Achten Sie auf diese spezifischen Probleme:
Fokus-Sichtbarkeit. Können Sie immer sehen, welches Element gerade fokussiert ist? Ein sichtbarer Fokusindikator ist nach WCAG 2.4.7 (Level AA) erforderlich. Viele Websites entfernen die Standard-Browser-Umrandung aus ästhetischen Gründen und vergessen, sie durch etwas Besseres zu ersetzen. Wenn Sie den Überblick verlieren, wo Sie sich auf der Seite befinden, ist das ein Fehler.
Tab-Reihenfolge. Bewegt sich der Fokus in einer logischen Reihenfolge durch die Seite? Er sollte der visuellen Lesereihenfolge folgen, im Allgemeinen von links nach rechts und von oben nach unten für LTR-Sprachen. Wenn der Fokus erratisch über die Seite springt, stimmt die zugrunde liegende DOM-Reihenfolge wahrscheinlich nicht mit dem visuellen Layout überein.
Tastaturfallen. Können Sie das aktuelle Element immer verlassen? Versuchen Sie, in jede interaktive Komponente hinein- und herauszutabben: Menüs, Modals, Datumsauswahlen, Videoplayer, eingebettete Karten, Karussells. Wenn Sie feststecken und sich weder mit Tab noch Escape befreien können, ist das eine Tastaturfalle und ein Level-A-Fehler, die schwerwiegendste Art.
Interaktive Funktionalität. Können Sie jede Funktion bedienen? Jedes Dropdown öffnen, jedes Formular absenden, jedes Video abspielen, jedes Popup schließen, jeden mehrstufigen Prozess abschließen. Wenn eine Funktionalität nur mit der Maus erreichbar ist, ist sie nicht barrierefrei.
Skip-Links. Bietet die Website einen Link "Zum Hauptinhalt springen" an, der beim Tabben erscheint? Ohne ihn müssen Tastaturnutzer auf jeder einzelnen Seite durch die gesamte Navigation tabben.
Schritt 4: Screenreader-Tests
Screenreader-Tests enthüllen eine völlig andere Dimension Ihrer Website. Inhalte, die visuell perfekt organisiert aussehen, können ein zusammenhangloses Chaos sein, wenn sie sequentiell vorgelesen werden.
Laut der WebAIM Screen Reader User Survey Nummer 10 hält JAWS einen Marktanteil von 41 % auf dem Desktop, NVDA folgt mit 38 %, und VoiceOver dominiert mobil mit 70,6 %. Sie müssen nicht mit allen testen, aber Sie sollten mit mindestens einem Desktop-Reader und einem mobilen Reader testen.
Für die Praxis beginnen Sie mit NVDA unter Windows (kostenlos) oder VoiceOver auf dem Mac (integriert, aktivieren mit Befehlstaste plus F5). Auf Mobilgeräten verwenden Sie VoiceOver auf iOS oder TalkBack auf Android.
Worauf Sie beim Screenreader-Test achten sollten:
Seitenstruktur. Wenn Sie nach Überschriften navigieren (drücken Sie H in NVDA oder verwenden Sie den Rotor in VoiceOver), spiegeln die Überschriften die Inhaltshierarchie korrekt wider? Gibt es übersprungene Ebenen, wie ein Sprung von h2 zu h4? Hat jeder Abschnitt eine aussagekräftige Überschrift?
Bildbeschreibungen. Navigieren Sie zu jedem Bild und hören Sie sich den Alt-Text an. Ist er beschreibend und nützlich? Ein Alt-Text von "Foto" auf einem Produktbild besteht den Test nicht, obwohl automatisierte Tools es als vorhandenen Alt-Text markieren würden. Dekorative Bilder sollten leere Alt-Attribute haben, damit Screenreader sie vollständig überspringen.
Formular-Interaktionen. Tabben Sie durch jedes Formular. Kündigt jedes Feld seine Beschriftung an? Werden Pflichtfelder angezeigt? Wenn Sie mit Fehlern absenden, werden die Fehlermeldungen angesagt und den richtigen Feldern zugeordnet? Können Sie einfach zwischen Fehlermeldungen navigieren?
ARIA-Nutzung. Hier schaffen viele Websites mehr Probleme als sie lösen. Seiten mit ARIA-Attributen hatten laut WebAIM Million 2025 tatsächlich 34,2 % mehr erkannte Fehler als Seiten ohne ARIA. Das liegt nicht daran, dass ARIA schlecht ist, sondern weil es häufig falsch eingesetzt wird. Achten Sie auf falsche Rollenansagen, fehlende Zustände und Widgets, die eine Sache ansagen, aber etwas anderes tun.
Dynamische Inhalte. Wenn sich Inhalte auf der Seite ändern, kündigt der Screenreader sie an? Dazu gehören Formular-Validierungsmeldungen, Ladezustände, Benachrichtigungsbanner, Live-Chat-Widgets und alle Inhalte, die über JavaScript ohne Seitenneuladung aktualisiert werden. ARIA-Live-Regionen handhaben das, aber sie müssen korrekt implementiert sein.
Schritt 5: Farbe und Kontrast prüfen
Farbkontrast-Fehler sind das häufigste Barrierefreiheitsproblem im Web und betreffen 79,1 % der Top-Eine-Million-Startseiten laut WebAIM. Die gute Nachricht ist, dass Kontrastprobleme einfach zu identifizieren und zu beheben sind.
Die WCAG definieren drei Kontrastschwellen. Normaler Text (unter 18pt oder unter 14pt fett) benötigt ein Kontrastverhältnis von 4,5 zu 1 gegenüber seinem Hintergrund. Großer Text (18pt und größer, oder 14pt fett und größer) benötigt 3 zu 1. Benutzerschnittstellenkomponenten und grafische Objekte, die Informationen vermitteln, benötigen 3 zu 1.
Verwenden Sie den Colour Contrast Analyser (kostenlos, von TPGi), um spezifische Farbkombinationen zu prüfen, oder nutzen Sie die in Ihren automatisierten Tools aus Schritt 2 integrierten Kontrastprüfungen. Achten Sie besonders auf Text über Bildern oder Farbverläufen, wo der Kontrast über das Element hinweg variieren kann. Platzhaltertext in Formularfeldern ist berüchtigt dafür, Kontrastanforderungen zu verfehlen.
Über Kontrastverhältnisse hinaus prüfen Sie, ob Ihre Website nicht ausschließlich auf Farbe angewiesen ist, um Informationen zu vermitteln. Fehlermeldungen sollten nicht einfach rot werden; sie brauchen auch ein Symbol oder eine Textbeschriftung. Diagramme und Grafiken benötigen Muster oder Beschriftungen zusätzlich zur Farbcodierung. Linktext innerhalb von Absätzen sollte einen nicht-farblichen Indikator wie eine Unterstreichung haben, nicht nur eine andere Farbe.
Schritt 6: Inhaltsqualität überprüfen
Dieser Schritt geht über die technische Konformität hinaus in die Effektivität der Inhalte. Automatisierte Tools melden das Vorhandensein oder Fehlen von Elementen, aber sie können keine Qualität beurteilen. Hier brauchen Sie menschliche Augen und Urteilsvermögen. Alt-Text-Qualität. Jedes informative Bild braucht Alt-Text, der denselben Zweck wie das Bild erfüllt. Ein Foto einer Teambesprechung sollte relevante Details beschreiben, nicht einfach "Meeting" sagen. Ein Diagramm sollte den wichtigsten Datenpunkt oder Trend vermitteln. Komplexe Bilder wie Infografiken benötigen möglicherweise eine längere Beschreibung über eine verlinkte Textalternative. Überschriftenstruktur. Ihre Überschriftenhierarchie sollte sich wie ein Inhaltsverzeichnis lesen. Screenreader-Nutzer navigieren häufig nach Überschriften, um Seiteninhalte zu scannen, daher müssen Ihre Überschriften beschreibend und korrekt verschachtelt sein. Keine Ebenen überspringen. Keine Überschriften-Tags verwenden, nur um Text größer zu machen. Seitensprache. Jede Seite muss ihre Sprache im HTML-lang-Attribut deklarieren. Inhalte in einer anderen Sprache innerhalb der Seite (ein englisches Zitat auf einer deutschen Seite zum Beispiel) benötigen ein lang-Attribut auf ihrem Container. Fehlende Dokumentsprache ist einer der häufigsten WCAG-Fehler. Formulardesign. Jedes Formularfeld braucht ein sichtbares, zugeordnetes Label. Gruppieren Sie zusammengehörige Felder mit fieldset und legend. Geben Sie klare Anweisungen vor dem Formular, nicht nur darin. Fehlermeldungen sollten das Problem spezifisch identifizieren ("E-Mail-Adresse muss ein @-Zeichen enthalten") statt generisch ("Ungültige Eingabe"). Stellen Sie sicher, dass die Fehlerbehebung einfach ist und zuvor eingegebene gültige Daten nicht löscht. Datentabellen. Verwenden Sie korrekte Tabellenüberschriften (th-Elemente) mit scope-Attributen. Vermeiden Sie die Verwendung von Tabellen für das Layout. Komplexe Tabellen mit zusammengeführten Zellen benötigen zusätzliches Markup wie headers-Attribute, um für Assistive-Technologie-Nutzer verständlich zu bleiben. Für einen breiteren Kontext zu Compliance-Anforderungen deckt unser ADA-Compliance-Leitfaden die rechtlichen Standards ab, die Ihre Inhalte erfüllen müssen.Schritt 7: Auf Mobilgeräten testen
Mobile Barrierefreiheitstests fangen Probleme auf, die Desktop-Tests vollständig übersehen. Über 60 % des Web-Traffics kommt von Mobilgeräten, und Menschen mit Behinderungen sind intensive Mobilnutzer, da Smartphones hervorragende integrierte Barrierefreiheitsfunktionen haben.
Berührungszielgröße. WCAG 2.2 verlangt, dass interaktive Elemente mindestens 24 mal 24 CSS-Pixel für Level-AA-Konformität groß sind, mit einer Empfehlung von 44 mal 44 Pixeln für AAA. Messen Sie Ihre Buttons, Links, Formularfelder und jedes antippbare Element. Achten Sie besonders auf Elemente, die dicht beieinander liegen, wie Navigationslinks in einer Fußzeile oder Aktionsbuttons in einer Liste. Kleine, gedrängte Ziele sind ein Albtraum für Nutzer mit motorischen Einschränkungen.
Zoom und Umfluss. Zoomen Sie auf 200 % und dann auf 400 %. Inhalte sollten in eine einzelne Spalte umfließen, ohne horizontales Scrollen, ohne überlappende Elemente und ohne Funktionalitätsverlust. Nutzer mit Sehbehinderungen zoomen häufig, und eine Website, die bei 200 % bricht, verstößt gegen WCAG 1.4.4.
Ausrichtung. Ihre Website sollte sowohl im Hoch- als auch im Querformat funktionieren, es sei denn, eine bestimmte Ausrichtung ist wesentlich (was extrem selten ist). Manche Nutzer montieren ihre Geräte aufgrund körperlicher Einschränkungen in einer festen Ausrichtung.
Berührungsgesten. Wenn Ihre Website komplexe Gesten wie Zusammenziehen, Mehrfinger-Wischen oder langes Drücken verwendet, bieten Sie Einzelzeiger-Alternativen an. Ein Karussell, das Wischen erfordert, braucht auch Zurück- und Weiter-Buttons.
Testen Sie mit VoiceOver auf iOS und TalkBack auf Android. Die Erfahrung unterscheidet sich deutlich von Desktop-Screenreadern, und Sie finden möglicherweise Probleme, die spezifisch für mobile Assistive-Technologie-Interaktionsmuster sind.
Schritt 8: Ergebnisse dokumentieren und berichten
Alles, was Sie in den Schritten 2 bis 7 gefunden haben, muss in einem handlungsorientierten Bericht organisiert werden. Das ist keine Dokumentation um der Dokumentation willen; ein gut strukturierter Bericht bestimmt, ob Probleme tatsächlich behoben werden oder für immer im Backlog liegen. Ein starker Audit-Bericht enthält sechs Abschnitte. Beginnen Sie mit einer Zusammenfassung für die Geschäftsleitung, die das Gesamtkonformitätsniveau und das Risiko für nicht-technische Stakeholder kommuniziert. Fügen Sie eine numerische Bewertung oder Note und eine klare Aussage über ihre Bedeutung hinzu. Entscheidungsträger müssen die Situation in unter zwei Minuten verstehen. Dokumentieren Sie dann Ihren Umfang und Ihre Methodik: welche Seiten getestet wurden, welche Tools und Techniken verwendet wurden, welche WCAG-Version und welches Konformitätsniveau Sie gemessen haben und etwaige Einschränkungen des Audits. Organisieren Sie dann die Ergebnisse nach WCAG-Prinzip. Gruppieren Sie Probleme unter Wahrnehmbar, Bedienbar, Verständlich und Robust. Innerhalb jedes Prinzips listen Sie die spezifischen Erfolgskriterien auf, die nicht erfüllt wurden. Diese Struktur entspricht der WCAG-Organisation und erleichtert Entwicklern das Finden relevanter Anleitungen. Für jedes einzelne Problem fügen Sie das WCAG-Erfolgskriterium, den Schweregrad (kritisch, schwerwiegend, mäßig oder gering), die betroffenen Seiten oder Komponenten, eine klare Problembeschreibung, einen Screenshot oder Code-Ausschnitt und eine spezifische Empfehlung mit Code-Beispielen hinzu. Nach den Ergebnissen liefern Sie eine Maßnahmen-Roadmap mit priorisierten Phasen. Mehr zur Priorisierung im nächsten Abschnitt. Schließlich fügen Sie einen Retest-Plan hinzu, der festlegt, wann und wie Sie die korrekte Umsetzung der Korrekturen überprüfen. Ein Audit ohne Retest-Zyklus ist nur die halbe Arbeit. Wenn Sie nach Ihrem Audit eine Barrierefreiheitserklärung veröffentlichen müssen, bietet unsere Vorlage für Barrierefreiheitserklärungen ein sofort verwendbares Format.Wie Sie priorisieren, was zuerst behoben werden soll
Sie haben Ihren Audit-Bericht. Er listet wahrscheinlich Dutzende, vielleicht Hunderte von Problemen auf. Wo fangen Sie an?
Klassifizieren Sie zunächst jedes Problem nach Schweregrad. Kritische Probleme blockieren den Zugang vollständig: eine Tastaturfalle, die den Checkout verhindert, ein Formular ganz ohne Labels, ein Video ohne Untertitel. Schwerwiegende Probleme machen Aufgaben sehr schwierig, aber nicht unmöglich. Mäßige Probleme verursachen Frustration. Geringfügige Probleme sind technisch nicht konform, haben aber begrenzten Einfluss in der Praxis.
Wenden Sie dann eine Priorisierungsformel an: Reichweite mal Auswirkung mal Aufwand. Reichweite fragt, wie viele Seiten oder Nutzer betroffen sind. Auswirkung fragt, wie stark das Problem die Aufgabenerfüllung beeinträchtigt. Aufwand fragt, wie viel Arbeit die Behebung erfordert. Probleme mit hoher Reichweite, hoher Auswirkung und geringem Aufwand stehen ganz oben auf der Liste.
In der Praxis funktioniert diese Reihenfolge am besten. Beheben Sie zuerst Probleme auf Template-Ebene, da sie sich auf jede Seite auswirken, die dieses Template verwendet. Ein fehlender Skip-Link in Ihrem Header-Template? Einmal beheben, und jede Seite ist korrigiert. Das ist enormer Hebel.
Beheben Sie dann kritische Probleme auf Seiten mit hohem Traffic und hoher Konversion. Ihre Startseite, Produktseiten, der Checkout-Prozess und Kontaktformulare verdienen Priorität, da sie die meisten Nutzer und den meisten Umsatz betreffen.
Arbeiten Sie dann schwerwiegende und mäßige Probleme systematisch ab. Gruppieren Sie nach Komponente: Beheben Sie alle Überschriftenprobleme auf einmal, dann alle Formularprobleme, dann alle Bildprobleme. Stapelweise nach Typ ist effizienter als seitenweise.
Heben Sie rein kosmetische oder Randfall-Probleme für eine Wartungsphase auf. Sie zählen, aber sie sollten die wirkungsvollere Arbeit nicht verzögern.
Die besten Tools für Barrierefreiheits-Audits
Nach dem Test Dutzender Tools über Hunderte von Audits hinweg, hier ist, was in der Praxis tatsächlich funktioniert. Bei kostenlosen Tools ist WAVE hervorragend für visuelle Lerner, da es Symbole direkt auf Ihrer Seite überlagert und zeigt, wo Probleme auftreten. axe DevTools ist die Referenz-Browser-Erweiterung für Entwickler mit klaren Erklärungen und Detail auf Code-Ebene. Lighthouse ist praktisch, da es in Chrome integriert ist und Barrierefreiheit mit Performance- und SEO-Prüfungen kombiniert. Pa11y ist leistungsstark für CI/CD-Integration. Der Colour Contrast Analyser von TPGi erledigt die Kontrastprüfung mit einem Pipetten-Tool. Web-accessibility-checker.com bietet einen kostenlosen Scan, der Ihre Seite in unter einer Sekunde auf DOM-Probleme prüft und mit einer tieferen PageSpeed-Insights-Analyse folgt. Die kostenpflichtigen Monitoring-Pläne fügen geplantes Scanning, historisches Tracking und Multi-Page-Abdeckung hinzu. Bei kostenpflichtigen Enterprise-Tools ist Siteimprove umfassend, aber teuer mit etwa 28.000 Dollar pro Jahr. AudioEye beginnt bei 45 Dollar pro Monat für automatisiertes Monitoring. axe Monitor von Deque erweitert die kostenlose axe-Engine mit Dashboard-Reporting und Team-Funktionen. Level Access bietet vollständiges Auditing mit Expertenconsultants. Die ehrliche Wahrheit ist, dass kein einzelnes Tool ausreicht. Kombinieren Sie einen kostenlosen Scanner für schnelle Prüfungen, eine Browser-Erweiterung für die Entwicklung und manuelle Tests für Vollständigkeit. Das beste Tool ist das, das Ihr Team tatsächlich konsequent nutzt.Was automatisierte Tools nicht erkennen können
Die Grenzen der Automatisierung zu verstehen macht Sie zu einem besseren Auditor. Hier sind die Kategorien, die durchgehend menschliches Urteilsvermögen erfordern.
Alt-Text-Qualität ist das klassische Beispiel. Automatisierte Tools überprüfen, ob Alt-Attribute existieren, können aber nicht bewerten, ob sie aussagekräftig sind. Ein Bild mit dem Alt-Text "DSC_0042.jpg" besteht automatisierte Prüfungen, versagt aber bei echten Nutzern völlig.
Tastaturfallen-Erkennung ist teilweise automatisierbar, aber unzuverlässig. Automatisierte Tools können grundlegende Tab-Navigation prüfen, aber komplexe Widgets mit bedingter Fokusverwaltung erfordern oft eine echte Person, die Tasten drückt.
Lesereihenfolge versus visuelle Reihenfolge. CSS Grid und Flexbox machen es einfach, Layouts zu erstellen, bei denen die visuelle Reihenfolge von der DOM-Reihenfolge abweicht. Automatisierte Tools prüfen das DOM; nur ein Mensch mit Screenreader oder Tab-Taste bemerkt, wenn Dinge in der falschen Reihenfolge gelesen werden.
Kognitive Barrierefreiheit ist fast ausschließlich eine Frage des menschlichen Urteils. Ist die Sprache zu komplex? Sind Anweisungen klar? Ist die Navigation vorhersehbar? Sind Fehlermeldungen hilfreich?
ARIA-Korrektheit jenseits der Syntax. Automatisierte Tools können überprüfen, ob ein ARIA-Attribut einen gültigen Wert hat, aber sie können nicht sagen, ob role="button" auf einem div, das wie ein Link aussieht und sich so verhält, semantisch falsch ist. Der WebAIM Million stellte fest, dass Seiten mit ARIA 34,2 % mehr Fehler hatten als Seiten ohne.
Die echte Nutzererfahrung. Kein Tool kann Ihnen sagen, ob Ihr Checkout-Prozess mit einem Screenreader tatsächlich benutzbar ist. Das erfordert einen Menschen, der den gesamten Prozess durchläuft und bewertet, ob die Gesamterfahrung Sinn ergibt.
Die am häufigsten nicht erfüllten WCAG-Kriterien
Die häufigsten Fehler zu kennen hilft Ihnen, Ihr Audit zu fokussieren und Ihre Erwartungen zu kalibrieren. Der WebAIM Million 2025 analysierte die Startseiten der Top-Eine-Million-Websites und fand diese führenden Probleme. Text mit geringem Kontrast erschien auf 79,1 % der Seiten. Dies ist mit großem Abstand der häufigste Barrierefreiheitsfehler im Web. Hellgrauer Text auf weißem Hintergrund, trendige Farbschemata mit geringem Kontrast und unzureichender Platzhaltertext-Kontrast sind die üblichen Ursachen. Fehlender Alternativtext für Bilder betraf 55,5 % der Seiten. Das umfasst Bilder ganz ohne Alt-Attribut und Bilder mit leerem Alt auf nicht-dekorativen Inhalten. Fehlende Formularbeschriftungen betreffen eine riesige Anzahl von Seiten. Wenn ein Formularfeld keine programmatische Beschriftung hat, müssen Screenreader-Nutzer raten, welche Informationen einzugeben sind. Platzhaltertext ist kein akzeptabler Ersatz für ein Label. Leere Links und leere Buttons sind Links oder Buttons, die keinen barrierefreien Text enthalten. Ein Link, der nur ein Symbol ohne Alt-Text oder aria-label umhüllt, oder ein Button mit nur einem Hintergrundbild, verfehlt dieses Kriterium. Fehlende Dokumentsprache ist eines der am einfachsten zu behebenden Probleme. Das Hinzufügen von lang="de" zum HTML-Tag dauert fünf Sekunden, dennoch lässt ein erheblicher Prozentsatz der Seiten es immer noch aus. All dies sind Level-A-Verstöße, die grundlegendste Stufe der Barrierefreiheit. Wenn Ihre Website auf Level A versagt, hat sie fundamentale Probleme, die dringend Aufmerksamkeit erfordern. Unsere EAA-Compliance-Seite erklärt, wie diese Kriterien europäischen rechtlichen Anforderungen entsprechen.Kosten, ROI und der Business Case
Barrierefreiheits-Audits haben klare Kosten und noch klarere Erträge. Die Zahlen zu kennen hilft Ihnen, Budget zu sichern und die Investition zu rechtfertigen.
Bei den Kosten liegt ein professionelles Audit einer kleinen bis mittleren Website typischerweise zwischen 1.250 und 5.500 Dollar, je nach Umfang und Komplexität. Audits auf Enterprise-Niveau mit Hunderten von Templates und komplexen Anwendungen reichen von 25.000 bis 40.000 Dollar oder mehr. DIY-Audits mit dem Prozess in diesem Leitfaden kosten hauptsächlich Personalzeit.
Betrachten Sie nun die Risikoseite. Der durchschnittliche Vergleich bei einer ADA-Barrierefreiheitsklage liegt bei etwa 25.000 Dollar, und das schließt Anwaltskosten, Sanierungskosten oder Reputationsschäden nicht ein. Mit über 5.100 Klagen im Jahr 2025 ist dies kein theoretisches Risiko.
Die ROI-Zahlen sind überzeugend. Forrester-Forschung ergab etwa 100 Dollar Rendite pro investiertem Dollar in Barrierefreiheitsverbesserungen. Websites, die ihre Barrierefreiheit verbessern, verzeichnen durchschnittlich 23 % mehr organischen Traffic. Von Anfang an barrierefrei zu bauen spart 67 % gegenüber nachträglicher Anpassung.
Vielleicht die eindrucksvollste Zahl: Die Warenkorbabbruchrate sinkt von etwa 69 % auf nicht barrierefreien E-Commerce-Seiten auf etwa 23 % auf barrierefreien Seiten. Wenn Menschen Ihre Website tatsächlich nutzen können, kaufen sie. Das allein kann die gesamten Kosten eines Audits und Sanierungsprogramms um ein Vielfaches rechtfertigen.
Der Business Case schreibt sich selbst. Ein Audit ist keine Ausgabe. Es ist eine Investition, die rechtliches Risiko reduziert, Ihren Markt erweitert, SEO verbessert und Konversionen steigert.