Website WCAG-2.2-konform machen

Ihre Website WCAG 2.2-konform zu machen, ist ein Prozess, keine einmalige Korrektur. Konformität ist das Ergebnis eines wiederholbaren Workflows: den Standard verstehen, den Ist-Zustand messen, die richtigen Dinge in der richtigen Reihenfolge beheben, mit echter assistiver Technologie und echten Nutzern validieren, das Ergebnis dokumentieren und Rückschritte verhindern. Dieser Leitfaden verwandelt diesen Workflow in eine konkrete, schrittweise Roadmap, die Ihr Team noch heute einsetzen kann — ohne auf Barrierefreiheits-„Overlays” zurückzugreifen, die Probleme im DOM überdecken, statt sie zu beheben, und die wiederholt in Klagen genannt wurden.

Schritt 1: Verstehen, was WCAG 2.2 tatsächlich verlangt

Bevor Sie etwas prüfen, machen Sie sich das Ziel klar. Die Web Content Accessibility Guidelines sind um vier Prinzipien herum organisiert, zusammengefasst im Akronym POUR:

Perceivable (Wahrnehmbar) — Nutzer müssen die Inhalte wahrnehmen können. Denken Sie an Textalternativen für Bilder, Untertitel und Transkripte für Medien sowie ausreichenden Farbkontrast.
Operable (Bedienbar) — jede Funktion muss ohne Maus funktionieren. Volle Tastaturbedienbarkeit, sichtbare Fokusindikatoren und keine Tastaturfallen sind zentrale Anforderungen.
Understandable (Verständlich) — Inhalte und Verhalten müssen vorhersehbar sein. Klare Beschriftungen, konsistente Navigation, hilfreiche Fehlermeldungen und lesbare Sprache gehören hierher.
Robust — das Markup muss von aktueller und künftiger assistiver Technologie verarbeitbar sein, was in der Praxis valides HTML und die korrekte Verwendung von ARIA-Namen, -Rollen und -Werten bedeutet.

Jedes Prinzip gliedert sich in testbare Erfolgskriterien, und jedem Kriterium ist eine Konformitätsstufe zugeordnet: A (grundlegend), AA (die rechtliche und praktische Basis, die die meisten Organisationen anstreben) und AAA (erweitert). Wenn jemand „WCAG 2.2 AA” sagt, meint er die Erfüllung jedes Erfolgskriteriums der Stufen A und AA. WCAG 2.2 ergänzt neun neue Kriterien gegenüber 2.1 — darunter Fokus nicht verdeckt, Ziehbewegungen, Zielgröße (Minimum) und Barrierefreie Authentifizierung — von denen die meisten die Erfahrung für Nutzer mit Tastatur, Sehbehinderung und motorischen Einschränkungen verbessern.

Es hilft zu wissen, warum dies das Ziel ist. AA-Konformität wird von den Gesetzen und Vorschriften referenziert, die höchstwahrscheinlich auf Sie zutreffen: Lesen Sie sich in die WCAG-Konformität als technischen Standard ein und sehen Sie dann, wie sie auf den European Accessibility Act, den ADA für private und öffentliche US-Einrichtungen und Section 508 für US-Bundesbehörden und deren Lieferanten abgebildet wird. Wenn Sie unterwegs über Begriffe stolpern, halten Sie unser Barrierefreiheits-Glossar in einem Tab geöffnet.

Zwei weitere Konzepte prägen jede ehrliche Konformitätsaussage. Das erste ist der Konformitätsumfang: WCAG-Konformität gilt für vollständige Seiten, nicht für isolierte Komponenten, und für vollständige Prozesse (z. B. einen gesamten Checkout-Ablauf) — Sie können eine Seite nicht als konform bezeichnen, wenn ein Schritt einer mehrstufigen Aufgabe fehlschlägt. Das zweite ist barrierefrei unterstützte Technologie: Sie dürfen sich nur auf solche Nutzungsweisen einer Funktion verlassen, die von der assistiven Technologie Ihrer Nutzer tatsächlich unterstützt werden. In der Praxis bedeutet das, mit aktuellen Screenreadern und Browsern zu testen, statt anzunehmen, dass valides Markup allein ein nutzbares Ergebnis garantiert. Behalten Sie beides im Blick, wenn Sie in den folgenden Schritten Ihren Arbeitsumfang abstecken; sie bestimmen, was Sie vertretbar als erreicht bezeichnen können.

Schritt 2: Einen automatisierten Basis-Scan durchführen

Sie können nicht beheben, was Sie nicht messen können — schaffen Sie also eine Ausgangsbasis. Automatisiertes Testen ist schnell, wiederholbar und hervorragend darin, die zahlreichen, mechanischen Fehler zu erfassen, die die meisten Websites plagen: fehlende Alternativtexte, niedriger Farbkontrast, leere Links und Schaltflächen, unbeschriftete Formularfelder, fehlende Dokumentsprache und doppelte IDs.

Werkzeuge, die auf der Open-Source-Engine axe-core basieren — darunter QualiBooths Software zum Scannen der Barrierefreiheit — erstellen in wenigen Minuten eine priorisierte Liste von Problemen. Wenn Sie nur einen schnellen Überblick über Ihren Stand wünschen, beginnen Sie mit einem kostenlosen Barrierefreiheits-Scan einiger wichtiger Seiten.

Einige Regeln, um Ihre Ausgangsbasis ehrlich zu halten:

Scannen Sie repräsentative Templates, nicht Ihre gesamte Website. Testen Sie Ihre Startseite, ein Inhalts-/Artikel-Template, eine Produkt- oder Kategorieseite, ein Formular (Registrierung, Checkout, Kontakt) und jedes authentifizierte Dashboard. Ein Template zu beheben behebt meist Hunderte von Seiten.
Testen Sie reale Zustände, nicht nur das initiale Laden. Öffnen Sie Menüs, klappen Sie Akkordeons auf, lösen Sie Modals aus und senden Sie Formulare mit Fehlern ab. Viele Verstöße erscheinen nur in interaktiven Zuständen.
Erfassen Sie die Zahlen. Halten Sie die Anzahl der Probleme nach Schweregrad und nach Erfolgskriterium fest. Das ist Ihr Vorher-/Nachher-Benchmark und die Grundlage Ihres Behebungs-Backlogs.

Seien Sie ehrlich über die Obergrenze: Automatisierte Werkzeuge erkennen zuverlässig nur 30–40 % der WCAG-Probleme. Ein sauberer automatisierter Scan ist notwendig, aber für eine echte Konformitätsaussage niemals ausreichend.

Schritt 3: Automatisierung durch ein manuelles Audit ergänzen

Die restlichen 60–70 % der WCAG-Kriterien erfordern menschliches Urteilsvermögen. Vermittelt dieser Alt-Text tatsächlich die Bedeutung des Bildes oder beschreibt er nur Pixel? Ist die Lese- und Fokusreihenfolge logisch? Sagen Fehlermeldungen dem Nutzer, wie er sich erholen kann? Wird ein benutzerdefiniertes Dropdown korrekt angesagt und können Sie es allein mit der Tastatur erreichen und bedienen? Keine Engine kann das zuverlässig beantworten.

Ein strukturiertes manuelles Audit deckt typischerweise ab:

Reine Tastaturbedienung — durch jedes interaktive Element tabben; einen sichtbaren Fokusindikator, eine logische Reihenfolge, keine Fallen und dass alles, was Sie mit der Maus tun können, auch ohne sie möglich ist, bestätigen.
Semantische Struktur — Überschriften in einer sinnvollen Hierarchie, Landmarks, als Listen ausgezeichnete Listen, Tabellen mit korrekten Überschriften.
Formulare — programmatische Beschriftungen, gruppierte Felder, klare Kennzeichnung von Pflichtfeldern und Fehlermeldungen, die mit den von ihnen beschriebenen Eingaben verknüpft sind.
Dynamische Inhalte — Modals, die den Fokus korrekt einfangen und wiederherstellen, Live-Regionen, die Aktualisierungen ansagen, und ARIA, das nur dort verwendet wird, wo natives HTML die Aufgabe nicht erfüllen kann.
Inhaltsqualität — aussagekräftiger Linktext, ausreichender Kontrast in realen Kontexten und Inhalte, die sich nicht allein auf Farbe oder Form verlassen.

Unser Leitfaden für manuelle Barrierefreiheits-Audits führt durch die vollständige Methodik, und die häufigen Barrierefreiheitsprobleme, die zu vermeiden sind sind eine schnelle Checkliste der Fehler, die Prüfer am häufigsten finden. Wenn Sie es lieber erledigen lassen möchten: QualiBooths Team für Barrierefreiheits-Beratung führt fachkundige manuelle Audits gegen die WCAG-2.2-AA-Kriterien durch.

Schritt 4: Priorisieren und beheben

Eine lange Liste von Verstößen ist überwältigend, bis Sie sie in eine Reihenfolge bringen. Triagieren Sie, indem Sie Nutzerauswirkung und Reichweite kombinieren:

Blocker zuerst. Alles, was eine Aufgabe für eine Gruppe von Nutzern unmöglich macht — Tastaturfallen, ein nicht zugänglicher Checkout, ein unbeschriftetes Login-Formular — kommt an die Spitze, unabhängig davon, wie viele Instanzen existieren.
Dann häufige, websiteweite Probleme. Ein Kontrast- oder Fokusproblem in Ihrem Header, Footer oder einer Designsystem-Komponente vervielfacht sich über jede Seite. Es einmal zu beheben bringt den größten Ertrag.
Dann seitenspezifische und inhaltliche Probleme. Einzelner fehlender Alt-Text, ein einzelnes falsch beschriftetes Bedienelement oder eine einmalige Überschriftenlücke.

Wenn Sie beheben, beheben Sie die Quelle, nicht das Symptom. Bevorzugen Sie native HTML-Elemente gegenüber ARIA-geflickten <div>s; korrigieren Sie die Designsystem-Komponente statt jeder einzelnen Seite, die sie nutzt; und gehen Sie die Grundursachen in Templates und geteilten Komponenten an, damit die Korrektur skaliert. Scannen Sie nach jedem Durchgang erneut, damit Sie die Zahlen fallen sehen und Rückschritte vermeiden. Dies ist auch der richtige Moment, Barrierefreiheit in Ihre Design-Tokens einzubacken — legen Sie kontrastsichere Farben, eine Mindestzielgröße von 24×24 px und sichtbare Fokusstile als Standards fest, damit neue Arbeit von Anfang an konform ist.

Einige Behebungsmuster wiederholen sich oft genug, um sie ausdrücklich zu nennen:

Nutzen Sie die Plattform. Ein natives <button>, <a href>, <input>, <select> und <dialog> bringt Tastaturverhalten, Fokusverwaltung und einen korrekten zugänglichen Namen kostenlos mit. Greifen Sie nur zu ARIA, um echte Lücken zu schließen — und denken Sie an die erste Regel von ARIA: Verwenden Sie kein ARIA, wenn ein natives Element ausreicht.
Benennen Sie Dinge programmatisch. Jedes Bedienelement braucht einen zugänglichen Namen aus einem <label>, aria-label oder aria-labelledby — nicht nur naheliegenden visuellen Text. Schaltflächen nur mit Symbol sind der häufigste Übeltäter.
Verwalten Sie den Fokus bewusst. Wenn ein Modal sich öffnet, bewegen Sie den Fokus hinein, fangen Sie ihn ein, solange es offen ist, und geben Sie ihn beim Schließen an den Auslöser zurück. Wenn sich Inhalte ohne Navigation aktualisieren, nutzen Sie eine Live-Region, damit Screenreader-Nutzer hören, was sich geändert hat.
Kodieren Sie Bedeutung nicht allein in Farbe oder Form. Kombinieren Sie Farbe mit Text, Symbolen oder Mustern, damit die Information für farbenblinde und sehbehinderte Nutzer erhalten bleibt.

Verfolgen Sie die Behebung in Ihrem üblichen Issue-Tracker, nach Erfolgskriterium getaggt, damit Barrierefreiheitsarbeit neben allem anderen sichtbar ist und nicht in einer separaten, veraltenden Tabelle lebt.

Schritt 5: Mit assistiver Technologie und Menschen mit Behinderungen testen

Bei Konformität geht es letztlich darum, ob echte Menschen Ihre Website nutzen können. Hier sind zwei Validierungsebenen wichtig, und sie sind nicht austauschbar.

Screenreader-Tests. Überprüfen Sie Ihre Korrekturen gegen die assistive Technologie, die Menschen tatsächlich verwenden: NVDA oder JAWS mit Chrome/Firefox unter Windows und VoiceOver mit Safari unter macOS und iOS. Achten Sie auf korrekte Namen, korrekte Rollen, angesagte Zustandsänderungen und eine sinnvolle Lesereihenfolge. Eine Screenreader-Evaluierung verschafft Ihnen einen professionellen Durchlauf über die wichtigsten Kombinationen, falls Ihrem Team die Erfahrung fehlt.

Usability-Tests mit Nutzern mit Behinderungen. Jedes Erfolgskriterium zu erfüllen ist die Untergrenze, nicht die Obergrenze — eine Website kann technisch konform und dennoch frustrierend in der Nutzung sein. Das zuverlässigste Signal kommt von Audits durch Menschen mit Behinderungen, die mit ihrer eigenen assistiven Technologie und ihren Gewohnheiten testen und Barrieren aufdecken, die Checklisten übersehen. Das ist der Unterschied zwischen dem Erfüllen des Buchstabens des Standards und dem Liefern echter digitaler Barrierefreiheit.

Schritt 6: Konformität dokumentieren (Erklärung und VPAT/ACR)

Sobald Sie behoben und validiert haben, halten Sie das Ergebnis fest. Dokumentation ist das, was „wir haben es versucht” in eine vertretbare, kommunizierbare Aussage verwandelt.

Barrierefreiheitserklärung. Eine öffentliche Seite, die Ihr Konformitätsziel angibt (z. B. WCAG 2.2 AA), beschreibt, was Sie getan haben, alle bekannten Einschränkungen auflistet und Nutzern eine Möglichkeit gibt, Probleme zu melden. Viele Vorschriften, einschließlich des EAA, erwarten eine solche.
VPAT / Accessibility Conformance Report. Ein ausgefülltes Voluntary Product Accessibility Template wird zu einem ACR — dem Standardartefakt, das Beschaffungsteams und Unternehmenskäufer als Nachweis anfordern. Unser Leitfaden „Was ist ein VPAT/ACR” erläutert das Dokument, und der Service VPAT-Berichte erstellt einen genauen, auditgestützten Bericht, den Sie Kunden und Rechtsteams aushändigen können.

Verfassen Sie diese auf Basis der Belege aus Ihren tatsächlichen Auditergebnissen, nicht auf Basis von Wunschvorstellungen. Ein VPAT, das die Konformität überzeichnet, ist eine Belastung, kein Vorteil.

Schritt 7: Konformität langfristig erhalten

Barrierefreiheit verschlechtert sich in dem Moment, in dem sich eine Website ändert — eine neue Komponente, ein neu gestaltetes Formular, ein Drittanbieter-Widget oder eine Inhaltsänderung kann unbemerkt Barrieren wieder einführen. Konformität ist ein Zustand, den Sie aufrechterhalten, kein Meilenstein, den Sie einmal passieren.

Bauen Sie Barrierefreiheit in Ihren Software-Lebenszyklus ein:

Shift left. Fügen Sie Ihrer Pipeline mit der CI/CD-Barrierefreiheits-Integration automatisierte Prüfungen hinzu, damit Verstöße bei Pull Requests erfasst werden, bevor sie ausgeliefert werden — der günstigstmögliche Ort, um sie zu beheben.
Produktion überwachen. Planen Sie wiederkehrende Barrierefreiheits-Audits, um Rückschritte und Inhaltsdrift zu erfassen, die Prüfungen vor der Veröffentlichung nicht sehen.
Ihr Team befähigen. Statten Sie Designer, Entwickler und Inhaltsautoren mit einem Barrierefreiheits-Toolkit und gemeinsamen Standards aus, damit Barrierefreiheit der Standard aller ist, nicht der nachträgliche Gedanke eines Spezialisten.
Im großen Maßstab steuern. Für große oder Multi-Site-Organisationen zentralisiert eine Plattform wie Agora Tracking, Reporting und Behebung über Teams hinweg.

Fehler, die Konformitätsbemühungen zum Scheitern bringen

Teams, die ins Stocken geraten, tun dies meist aus vorhersehbaren Gründen. Achten Sie auf diese:

Allein der Automatisierung vertrauen. Ein grüner automatisierter Bericht deckt nur ein Drittel der Kriterien ab. Ihn als Nachweis der Konformität zu behandeln, ist der häufigste — und rechtlich riskanteste — Fehler.
Ein Overlay kaufen. Overlays und „Barrierefreiheits-Widgets” versprechen sofortige Konformität, indem sie JavaScript einschleusen, das die Seite überschreibt. Sie beheben nicht den zugrunde liegenden Code, stören häufig die eigene assistive Technologie der Nutzer und wurden in einer wachsenden Zahl von Beschwerden genannt. Sie sind eine Abkürzung zum Risiko, nicht zur Konformität.
Seiten statt Systeme beheben. Einzelne Seiten zu beheben, während das Designsystem defekt bleibt, bedeutet, dass jede neue Seite dieselben Mängel wieder einführt. Beheben Sie zuerst geteilte Komponenten und Templates.
Es als einmaliges Projekt behandeln. Ohne CI/CD-Prüfungen und wiederkehrende Audits driftet eine konforme Website innerhalb weniger Release-Zyklen aus der Konformität.
Echte Nutzer auslassen. Technische Konformität ohne Usability-Tests kann Nutzer mit Behinderungen dennoch außerstande lassen, zentrale Aufgaben zu erledigen.

Diese zu vermeiden bewahrt Ihre Investition davor, in dem Moment zu versickern, in dem das Projekt „ausgeliefert wird”.

Alles zusammenfügen

Ein realistischer Weg zu WCAG 2.2 AA sieht so aus: die POUR-Prinzipien und das AA-Ziel lernen, einen automatisierten Basis-Scan durchführen, ein manuelles Audit darüberlegen, nach Auswirkung und Reichweite beheben, mit Screenreadern und Nutzern mit Behinderungen validieren, Ihre Konformität in einer Erklärung und einem VPAT dokumentieren und sie dann mit CI/CD-Prüfungen und wiederkehrenden Audits gesund halten. Jeder Schritt baut auf dem letzten auf — und nichts davon hängt von einem Overlay ab, das den echten Code übertüncht.

Fangen Sie klein an und bauen Sie Schwung auf: Scannen Sie diese Woche eine Handvoll Templates, beheben Sie die Kontrast- und Fokusstile Ihres Designsystems und setzen Sie eine automatisierte Prüfung in Ihre Pipeline. Von dort aus bringt Sie die obige Roadmap den Rest des Weges. Wenn Sie bereit sind, das Tempo zu erhöhen, entdecken Sie unsere Preise, fordern Sie eine Demo an oder sprechen Sie mit einem Experten über einen auf Ihren Stack zugeschnittenen Behebungsplan.