WCAG 2.2 ist inzwischen das maßgebliche AA-Ziel in der EU — über den European Accessibility Act und den harmonisierten Standard EN 301 549 — und de-facto-Maßstab, an dem US-Gerichte ADA-pflichtige Websites messen, auch wenn die Vorschriften noch 2.1 benennen. Der Standard ist gut dokumentiert; der Weg von „wir wissen, dass wir konform sein müssen“ zu „wir haben eine belastbare Haltung“ ist es nicht. Dieser Leitfaden ist dieser Weg — in sechs Schritten, in der Reihenfolge, in der ein Team ihn tatsächlich gehen sollte.

WCAG 2.2 ist die aktuelle Version der Richtlinien für barrierefreie Webinhalte (Web Content Accessibility Guidelines), die das W3C im Oktober 2023 als Empfehlung veröffentlicht hat. Sie definiert 86 Erfolgskriterien, gegliedert nach vier Prinzipien — Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein. Jedem Kriterium ist eine Konformitätsstufe zugeordnet. Stufe A ist die Mindestschwelle; Stufe AA ist der maßgebliche Maßstab jeder größeren Regulierungsbehörde; Stufe AAA ist ein Zielanspruch und nirgends eine regulatorische Mindestanforderung.

Wenn eine Regulierungsbehörde oder ein Vertrag „WCAG 2.2 AA-konform“ fordert, bedeutet das mehr als das Bestehen eines Tests auf einer einzelnen Seite. Die W3C-Konformitätsdefinition verlangt, dass die gesamte Konformitätseinheit — die Seite oder der Seitensatz, der einen Prozess bildet — jedes Kriterium der Stufen A und AA erfüllt, dass jeder Prozess von Anfang bis Ende barrierefrei ist und dass assistive Technologie nicht deaktiviert werden muss, damit der Inhalt funktioniert. Eine Website, die die meisten Kriterien auf den meisten Seiten erfüllt, ist nicht konform; die Messlatte ist vollständige Abdeckung.

WCAG 2.2 fügt gegenüber 2.1 neun neue Kriterien hinzu — Fokuserscheinungsbild, Zielgröße, Ziehen, redundante Eingabe, barrierefreie Authentifizierung, konsistente Hilfe und einige weitere. Websites, die WCAG 2.1 AA-konform waren, sind nicht automatisch WCAG 2.2 AA-konform; die neuen Kriterien sind dort, wo die Lücke entsteht. Die kriterienweise Referenz findet sich in unserem vollständigen WCAG-2.2-Erfolgskriterien-Verzeichnis.

Konformität ist eine Haltung, kein Zustand — eine Website, die am Montag konform ist, kann am Dienstag eine Regression ausliefern. Sie als einmaliges Projekt zu behandeln, ist der häufigste und teuerste Fehler im Feld.

Man kann nicht beheben, was man nicht gemessen hat — und ein einziges Werkzeug misst es nicht gut. Ein Baseline-Audit wird in drei Modi auf ungefähr denselben Seiten durchgeführt.

Modus 1 — Automatisiertes Scanning. Ein Scanner meldet maschinell prüfbare Fehler — fehlende Alternativtexte, fehlende Formular-Labels, zu geringer Farbkontrast, ungültiges ARIA, Probleme mit der Überschriftenstruktur. Er findet dichte, sich wiederholende Probleme, die man sonst manuell suchen müsste, kann aber nicht beurteilen, ob Alternativtexte sinnvoll sind, ob sich ein benutzerdefiniertes Widget unter einem Screenreader richtig anfühlt oder ob die Fokusreihenfolge kognitiv sinnvoll ist. Den Scan als Volumens-Baseline behandeln, nicht als Urteil. Zunächst den kostenlosen WCAG-2.2-Scanner auf den zehn wichtigsten Seiten ausführen — Homepage, Login, Checkout, zwei Produktseiten, Dashboard, Kontoeinstellungen, die Seite mit der Erklärung zur Barrierefreiheit (falls vorhanden) und die zwei Landingpages mit dem höchsten Traffic. Der Scan zeigt, ob hundert oder zehntausend Probleme vorliegen — die erste Information, die eine Behebungsverantwortliche oder ein Behebungsverantwortlicher benötigt.

Modus 2 — Manuelle Prüfung durch eine sehende Barrierefreiheits-Fachkraft. Eine geschulte Prüferin oder ein geschulter Prüfer, der dieselben Seiten durcharbeitet, findet, was die Automatisierung nicht beurteilen kann. Sind die Alternativtexte korrekt? Ist die Überschriftenstruktur logisch, nicht nur syntaktisch valide? Stellen eigene Widgets die richtigen Name-, Role- und State-Informationen bereit? Eine Fachkraft bearbeitet etwa 15 bis 20 Seiten pro Tag; das Ergebnis ist ein schriftlicher Bericht mit Reproduktionsschritten, die konkreten Erfolgskriterien zugeordnet sind.

Modus 3 — Usability-Audit mit Menschen, die assistive Technologie nutzen. Eine Screenreader-Nutzerin oder ein Screenreader-Nutzer führt den Checkout durch; eine tastaturgebundene Person navigiert das Dashboard; eine Person mit Sehbeeinträchtigung füllt das Kontaktformular bei 200-prozentiger Vergrößerung aus. Das Ergebnis ist qualitativ — „die Ankündigung beim Absenden erfolgt vor der Fokusbewegung, daher habe ich sie verpasst“ — und es ist die Schicht, die Konformität von Barrierefreiheit unterscheidet. Dieser Modus wird am häufigsten übersprungen; überspringt man ihn, besteht man Scans und Erklärungen, während die Nutzenden ihre Aufgaben weiterhin nicht erledigen können.

Die drei Modi ergänzen sich: Automatisierung findet das Volumen, Fachprüfung findet strukturelle und semantische Probleme, Nutzertests finden Erfahrungsversagen. Ein erster Baseline, der alle drei umfasst, dauert für eine mittelgroße Website zwei bis vier Wochen.

Ein Baseline-Audit einer typischen Website bringt Hunderte bis Tausende von Problemen zutage. Von oben einer flachen Liste zu beginnen ist ein Weg, drei Monate zu verbringen, ohne die Nadel zu bewegen. Die Priorisierung erfolgt auf zwei Achsen — Schweregrad und Reichweite.

Schweregrad gibt an, wie stark das Problem die Nutzungserfahrung unterbricht. Blocker verhindern die Aufgabenerledigung: ein Checkout-Button, den Screenreader nicht aktivieren können, ein Formularfeld ohne programmatisches Label, ein Modal, das den Fokus einfängt. Schwerwiegende Probleme erzeugen erhebliche Reibung, blockieren aber nicht: mehrdeutiger Linktext, fehlende Fokusstile, Fehlermeldungen, die sichtbar, aber nicht angekündigt sind. Geringfügige Probleme sind kosmetischer Natur oder betreffen nur enge AT-Konfigurationen: Kontrast knapp unter 4,5:1, dekorativer Alternativtext mit abschließendem Leerzeichen, übersprungene Überschriftenebene auf einer Fußnotenpage.

Reichweite gibt an, wie viele Nutzende auf das Problem stoßen. Ein mehrdeutiger Link in der globalen Navigation erreicht jede Besucherin und jeden Besucher auf jeder Seite. Ein unzugänglicher Datumsauswähler im Checkout erreicht jede kaufende Person. Eine unzugängliche Komponente im Pressebereich erreicht nahezu niemanden. Die Reichweite wird durch Analytics bestimmt, nicht durch die intrinsische Bedeutung des Problems.

Eine einfache Zwei-mal-zwei-Matrix genügt. Es geht nicht um Präzision — es geht darum, das Gespräch zu erzwingen, dass „ein Screenreader kann den Checkout nicht abschließen“ nicht dasselbe Problem ist wie „ein alt-Attribut mit einem abschließenden Leerzeichen auf der Presseseite“.

Die Priorisierung liefert einen priorisierten Backlog. Der Backlog — nicht der Auditbericht — ist die Grundlage, gegen die das Engineering arbeitet.

Die Behebungsarbeit gliedert sich auf nahezu jeder Website in dieselben Muster. Jede Kategorie ist einem oder mehreren WCAG-Erfolgskriterien zugeordnet; das vollständige WCAG-2.2-Erfolgskriterien-Verzeichnis ist die Referenzquelle.

Semantische HTML-Struktur. Die wirkungsvollste Behebung ist die Verwendung des richtigen Elements. Ein button ist kein div mit einem Click-Handler; eine Überschrift ist kein fett formatierter Text; eine Liste sind keine durch Zeilenumbrüche getrennten Absätze. Natives HTML bringt Name, Role und Tastaturverhalten kostenlos mit; es mit ARIA auf einem generischen Element neu zu erfinden ist der häufigste Entstehungsweg von Barrierefreiheitsfehlern. Zugeordnet SC 1.3.1 und SC 4.1.2.

Alternativtext für Bilder. Jedes bedeutungstragende Bild benötigt beschreibenden Alternativtext. Dekorative Bilder erhalten alt="" — kein fehlendes Attribut. Funktionale Bilder — Icons in Buttons, Bild-Links — erhalten Alternativtext, der die Aktion beschreibt, nicht das Bild. Zugeordnet SC 1.1.1.

Tastaturbedienbarkeit. Jedes interaktive Element muss ausschließlich mit der Tastatur erreichbar und bedienbar sein — mit Tab darauf navigieren, mit Enter oder Leertaste aktivieren, mit Escape verlassen. Eigene Widgets (Dropdowns, Modals, Tabs, Karussells, Datumsauswähler) sind die üblichen Problemquellen. Den Test durch Ausstecken der Maus durchführen. Zugeordnet SC 2.1.1 und SC 2.1.2.

Fokusverwaltung. Wenn der Fokus ein Element erreicht, muss er sichtbar sein; wenn sich etwas auf der Seite ändert, muss der Fokus an einer sinnvollen Stelle landen. Ein Modal, das geöffnet wird, sollte den Fokus in das Modal verschieben; beim Schließen sollte der Fokus zum auslösenden Element zurückkehren. WCAG 2.2 fügte SC 2.4.11 Fokus nicht verdeckt hinzu und verschärfte SC 2.4.7 Fokus sichtbar; der Fokusring ist keine optionale Gestaltungsmaßnahme mehr.

Farbkontrast. Text gegenüber seinem Hintergrund muss gemäß SC 1.4.3 bei normalem Text 4,5:1 und bei großem Text 3:1 erreichen; interaktive UI-Komponenten und Grafiken müssen gemäß SC 1.4.11 3:1 erreichen. Die meisten Verstöße liegen in Marketingoberflächen — Markenfarben, die auf dem kalibrierten Display des Designers richtig aussehen und auf einem echten Laptop versagen. Eine Kontrastprüfung im Design-Tooling verhindert die meisten Regressionen.

Formular-Labels und Fehlermeldungen. Jedes Feld benötigt ein programmatisches Label, nicht nur einen Platzhaltertext. Fehler müssen gegenüber assistiver Technologie angekündigt werden, dem auslösenden Feld zugeordnet sein und in handlungsorientierter Sprache beschrieben werden. „Ungültige Eingabe“ ist kein Label; „Die Telefonnummer muss die Ländervorwahl enthalten“ ist eines.

ARIA — Zurückhaltung, nicht Enthusiasmus. ARIA nur dann verwenden, wenn natives HTML nicht ausdrücken kann, was die Komponente tut. Ein nav ist besser als role="navigation"; ein button ist besser als role="button". Falsches ARIA ist schlechter als kein ARIA, weil es die assistive Technologie aktiv falsch informiert.

Ankündigungen dynamischer Inhalte. Wenn sich Inhalte ohne Seitenneuladen ändern — Toasts, Validierungsmeldungen, Suchergebnisse, die an Ort und Stelle aktualisiert werden — übersehen Screenreader dies, es sei denn, man teilt es ihnen mit. aria-live="polite" für nicht dringende Aktualisierungen verwenden und aria-live="assertive" nur für echte Unterbrechungen.

PDF-Barrierefreiheit. Jede veröffentlichte PDF muss PDF/UA erfüllen — dem WCAG-Äquivalent für Dokumente. PDFs sind in der Regel der größte blinde Fleck in einem Behebungsprogramm, weil sie außerhalb des Engineering-Bereichs verwaltet werden. Den PDF-Barrierefreiheits-End-to-End-Leitfaden für die Produktionspipeline konsultieren.

Die Behebungen interagieren miteinander. Ein div-Button durch ein button-Element zu ersetzen, behebt Tastatur-, Fokus-, Name-, Role- und Value-Kriterien in einer einzigen Änderung. Deshalb steht semantisches HTML oben — es zahlt sich über die meisten Kriterien für den geringsten Aufwand aus.

Eine Behebung ist erst abgeschlossen, wenn sie so verifiziert wurde, wie die betroffene Nutzerin oder der betroffene Nutzer sie konsumieren würde. Automatisierte Scanner erfassen unter großzügigen Annahmen rund 30 bis 40 Prozent der WCAG-Probleme — was bedeutet, dass die Mehrheit der Behebungen für das Werkzeug, das das Problem gemeldet hat, nicht sichtbar ist.

Die Mindest-AT-Testmatrix ist kurz. NVDA mit Firefox unter Windows ist die meistgenutzte Screenreader-Browser-Kombination auf dem Desktop; NVDA ist kostenlos. VoiceOver mit Safari unter macOS ist der Standard auf Apple-Desktops; VoiceOver mit Safari unter iOS ist der Standard auf Apple-Mobilgeräten, und das iOS-Gestenmodell unterscheidet sich vom Desktop genug, damit Mobile gesondert getestet werden muss. TalkBack mit Chrome unter Android rundet das mobile Spektrum ab. Nur Tastatur auf jedem interaktiven Ablauf erfordert keine assistive Technologie — nur das Ausstecken der Maus — und ist der einzige Test mit dem höchsten Einzelwert.

Für jede Behebung ist das Protokoll dasselbe. Die Seite im betreffenden Browser und Screenreader laden. Zum betroffenen Element ausschließlich mit assistiver Technologie navigieren. Es aktivieren. Beobachten, was angekündigt wird. Bestätigen, dass die Ankündigung dem entspricht, was eine sehende Person bei derselben Interaktion verstehen würde. Die Verifizierung dokumentieren — Datum, AT-Version, Browser-Version, Bestanden oder Nicht bestanden.

Muster, die Verifizierung findet, die Scans übersehen: ein Button, der ohne zugänglichen Namen angekündigt wird; ein Modal, das mit korrektem ARIA geöffnet wird, der Fokus aber am auslösenden Element bleibt, sodass die Screenreader-Nutzerin oder der Screenreader-Nutzer nicht weiß, dass es geöffnet wurde; ein eigenes Dropdown, das die korrekte Role bereitstellt, die ausgewählte Option aber nicht ankündigt, wenn sie sich ändert.

Verifizierung durch Nutzende mit Behinderungen ist ein stärkeres Signal als interne Tests. Eine sehende Entwicklerin oder ein sehender Entwickler, der VoiceOver steuert, prüft, ob die Technologie auf der Seite funktioniert; eine blinde Nutzerin oder ein blinder Nutzer, der VoiceOver steuert, prüft, ob die Seite für sie oder ihn funktioniert. Regulierungsbehörden und Gerichte behandeln das zweite als maßgeblich.

Eine Erklärung zur Barrierefreiheit ist das öffentliche Artefakt, das in klarer Sprache darlegt, welche Konformität die Website beansprucht, welche Teile noch nicht konform sind, wie Nutzende ein Problem melden können und wann all das zuletzt überprüft wurde. Gemäß dem European Accessibility Act ist sie für in den Anwendungsbereich fallende Dienste gesetzlich vorgeschrieben. Gemäß ADA Title III ist sie nicht gesetzlich vorgeschrieben, wird aber von US-Gerichten als Beleg für Bemühungen in gutem Glauben gewertet; ihr Fehlen wird als Gleichgültigkeit gewertet. In beiden Fällen wird sie veröffentlicht.

Eine belastbare Erklärung enthält fünf Elemente. Umfang — welche Domains, Anwendungen und Dokumente erfasst sind und was ausdrücklich ausgenommen ist. Konformitätsziel — in der Regel „WCAG 2.2 Level AA“ mit dem Datum, an dem es erreicht wurde oder erwartet wird. Bekannte Einschränkungen — konkrete Bereiche, in denen noch keine Konformität besteht, mit einem Behebungsdatum oder einer Begründung. Kontaktkanal — eine E-Mail-Adresse oder ein Formular mit einer zugesagten Antwortfrist. Datum der letzten Überprüfung — nicht älter als zwölf Monate.

Die EU-Mustervorlage für Erklärungen zur Barrierefreiheit ist der sauberste Ausgangspunkt. Die meisten Regulierungsbehörden akzeptieren eine Erklärung, die dieser Struktur folgt, auch wenn ihre Zuständigkeit sie nicht formell vorschreibt. Die Erklärung liegt unter einer URL wie /accessibility/, verlinkt aus der seitenweiten Fußzeile, und ist selbst barrierefrei — was das kleine Kontingent von Teams erwischt, die eine Erklärung als unzugängliche PDF veröffentlichen.

Die Erklärung ist kein Marketingtext. Es ist das, was eine Regulierungsbehörde, eine Klägerin oder ein Kläger oder eine beschaffende Stelle liest, bevor sie oder er irgendeine andere Maßnahme ergreift. Abschwächende Formulierungen („wir bemühen uns“, „wir glauben, weitgehend konform zu sein“) wirken wie Ausweichen; konkrete, datierte, nachprüfbare Angaben wirken wie ein glaubwürdiges Programm.

Die ersten fünf Schritte liefern eine Momentaufnahme. Der sechste Schritt macht sie dauerhaft. Web-Anwendungen ändern sich kontinuierlich, und jede Änderung ist eine Gelegenheit, ein Label zu beschädigen, einen Fokusring zu verlieren oder eine Komponente auszuliefern, die sich gegenüber NVDA als div ankündigt. Die Konformität, die letzten Monat erreicht wurde, übersteht die Deploys des nächsten Monats nicht, es sei denn, etwas überwacht sie.

Eine belastbare Monitoring-Haltung hat drei Schichten. Kontinuierliches automatisiertes Scanning läuft bei jedem Produktions-Deploy — oder zumindest täglich — und leitet Befunde in den Issue-Tracker des Engineering-Teams. Ein Triage-Workflow weist neue Befunde innerhalb eines definierten SLA einem Verantwortlichen zu — einen Arbeitstag für Blocker, einen Sprint für alles andere. Regelmäßiges manuelles Audit durch Tester mit Behinderungen — in einem quartalsweisen oder halbjährlichen Rhythmus — findet, was Automatisierung nicht sieht, und liefert die Dokumentation, nach der eine externe Auditorin oder ein externer Auditor oder eine Regulierungsbehörde fragen wird.

Die Plattformen, die diese Schichten kombinieren — automatisiertes Monitoring plus manuelle Audit-Übergabe in einem integrierten Workflow — sind die Kategorie, aus der die meisten Teams letztlich kaufen. Die vier 2026 am häufigsten in die engere Wahl kommenden sind axe Monitor mit der stärksten Browser-Engine-Genauigkeit und tiefsten Entwicklerintegration; Siteimprove mit der breitesten Content-Plattform-Abdeckung und der längsten Marktgeschichte; Level Access, das Plattform-Tooling mit einem erheblichen Professional-Services-Bereich verbindet; sowie Qualibooth, das sein Produkt um den Scan-Triage-Manuelle-Prüfung-Erklärung-Workflow als einen integrierten Pfad aufgebaut hat, wobei manuelle Verifizierung durch Tester mit Behinderungen inklusive und nicht separat verkauft ist. Jedes hat Abwägungen; die richtige Wahl hängt davon ab, ob der Engpass in Scan-Genauigkeit, Content-Plattform-Breite, Professional-Services-Kapazität oder Workflow-Integration liegt. Keines von ihnen nimmt die Pflicht ab, die Probleme zu beheben — sie zeigen, was zu beheben ist, nach einem Zeitplan, mit Nachweis.

Eine Wahl treffen. Die konkrete Plattform ist weniger wichtig als die Disziplin, eine kontinuierlich zu betreiben.

Overlay-Widgets. Ein Drittanbieter-Widget, das verspricht, eine Website durch Einbettung von JavaScript zur Laufzeit barrierefrei zu machen, tut das nicht. Das DOJ, der National Federation of the Blind und jede seriöse Barrierefreiheits-Beratung haben das öffentlich festgestellt, und die Rechtspraxis zeigt, dass overlay-geschützte Websites im selben Maße verklagt werden wie ungeschützte. Overlays ersetzen keine Behebungen; sie verbergen sie.

„Automatisierter Scan gleich konform.“ Ein sauberer Scan bestätigt nur, dass die Probleme, die der Scanner erkennen kann, nicht vorhanden sind. Der Wert von 30 bis 40 Prozent ist großzügig; bei einer komplexen Anwendung mit eigenen Widgets ist er geringer.

PDFs und eingebettete Videos vergessen. Dokumente und Videos werden in der Regel außerhalb des Engineering-Bereichs verwaltet und sind der konsistenteste blinde Fleck. PDFs benötigen PDF/UA-Konformität, Struktur-Tags und barrierefreie Leserreihenfolge; Videos benötigen Untertitel, Transkripte und Audiodeskription, wo zutreffend.

Native mobile Apps ignorieren. WCAG gilt für das mobile Web und für native iOS- und Android-Apps. Ein Team mit konformer Website und unzugänglichen Apps ist nicht konform.

Als einmaliges Projekt behandeln. Konformität verfällt mit dem nächsten Deploy. Der teuerste Fehler ist, in ein Baseline-Audit zu investieren, die Befunde zu beheben, den Sieg zu erklären und auf Monitoring zu verzichten.

Menschen mit Behinderungen nicht in Tests einbeziehen. Nutzende mit Behinderungen für den Usability-Audit-Modus und regelmäßige Verifizierungen zu marktüblichen Sätzen rekrutieren und vergüten.

Ein Werkzeug kaufen statt die Arbeit zu tun. Keine Plattform behebt Barrierefreiheitsprobleme eigenständig — die Behebung ist weiterhin Engineering-Arbeit. Ein Werkzeug ohne Behebungskapazität liefert ein Dashboard ungelöster Probleme und dieselbe Risikoexposition wie zuvor.

Konkrete Maßnahmen, die morgen beginnen können.

Wie lange dauert die Herstellung von WCAG 2.2-Konformität typischerweise?

Für eine mittelgroße kommerzielle Website beträgt der realistische erste Durchlauf acht bis zwölf Wochen vom Baseline-Audit bis zur veröffentlichten Erklärung, vorausgesetzt, ein oder zwei Entwicklerinnen oder Entwickler können etwa ein Drittel ihrer Zeit für die Behebung aufwenden. Eine komplexe Anwendung mit eigenen Widgets sowie umfangreichem PDF- oder Videoinventar benötigt routinemäßig sechs Monate. Die Konformität wird danach kontinuierlich aufrechterhalten; der erste Durchlauf ist der aufwendigste.

Benötige ich WCAG 2.2 AA oder AAA?

AA. Jede maßgebliche Regulierungsbehörde, die eine Stufe benennt — die ADA-Title-II-Regel 2024, der EAA über EN 301 549, die britischen Public-Sector-Bodies-Vorschriften, Section 508 — verweist auf Level AA. AAA ist ein Zielanspruch und nirgends eine regulatorische Mindestanforderung.

Kann ich einfach einen automatisierten Scanner verwenden?

Nein. Scanner erfassen unter großzügigen Annahmen rund 30 bis 40 Prozent der WCAG-Probleme. Sie können nicht beurteilen, ob Alternativtexte korrekt sind, ob eine Screenreader-Nutzerin oder ein Screenreader-Nutzer den Checkout abschließen kann oder ob ein eigenes Widget die richtigen Name-, Role- und State-Informationen bereitstellt. Eine belastbare Haltung kombiniert automatisiertes Monitoring mit regelmäßigen manuellen Audits durch Tester mit Behinderungen.

Gilt WCAG 2.2 auch für mobile Apps?

Ja, in der Praxis. Jede maßgebliche Regulierungsbehörde, die auf WCAG verweist, wendet dies auch auf das mobile Web und native iOS- und Android-Apps an. Native Apps haben zusätzliche plattformspezifische Leitlinien, aber die zugrundeliegenden Erfolgskriterien sind dieselben. Wer eine mobile App ausliefert, ist im Anwendungsbereich.

Was ist der Unterschied zwischen WCAG, ADA und EAA?

WCAG ist ein technischer Standard des W3C. Die ADA ist ein US-amerikanisches Bürgerrechtsgesetz. Der EAA ist eine EU-Richtlinie. Das Gesetz legt fest, ob eine Pflicht besteht; der Standard legt fest, wie sie erfüllt wird. US-Gerichte und das DOJ behandeln WCAG 2.1 AA als den maßgeblichen Maßstab für ADA-Konformität; der EAA verweist auf EN 301 549, der auf WCAG 2.1 AA verweist. WCAG 2.2 ist die Version, die 2026 jeder seriöse Auditor als Benchmark heranzieht.

Wie oft sollte ein Re-Audit erfolgen?

Kontinuierliches automatisiertes Scanning bei jedem Deploy, quartalsweise interne manuelle Prüfung der zehn wichtigsten Abläufe sowie ein vollständiges externes manuelles Audit durch Tester mit Behinderungen alle zwölf bis achtzehn Monate. Nach einem wesentlichen Redesign das Audit der betroffenen Oberfläche vor dem Livegang wiederholen.

Mit der Baseline beginnen. Den kostenlosen Barrierefreiheits-Scanner auf den zehn wichtigsten Seiten ausführen, die Zahlen erfassen und sie nutzen, um intern für die Behebung zu argumentieren. Während der Scan läuft, das Dossier für den eigenen Zuständigkeitsbereich lesen — den European Accessibility Act-Leitfaden für den EU-Markt, den ADA-Title-III-Leitfaden für die USA. Sobald die Baseline vorliegt, ist der manuelle Audit und kontinuierliche Monitoring-Schritt der, in den die meisten Teams zu wenig investieren; Qualibooth und die in Schritt 6 genannten Alternativen sind die Kategorie, die es dann zu evaluieren gilt.