Axively

WCAG 2.2 AA

WCAG-Audit für moderne Websites

Ein WCAG-Audit prüft, ob Menschen Ihre Website wahrnehmen, verstehen, durchsuchen und bedienen können. Für die meisten kommerziellen Webprojekte ist WCAG 2.2 Stufe AA das praktische Ziel: die Stufe, auf die viele Gesetze, Vergaberegeln und Barrierefreiheitsrichtlinien verweisen.

Axively testet öffentliche Seiten mit den axe-core-Regelsätzen für WCAG 2.1/2.2 A und AA, erklärt die Auswirkung jedes Verstoßes und liefert entwicklerfreundliche Korrekturvorschläge.

Audit checklist

  • Stellen Sie sicher, dass jedes interaktive Element einen zugänglichen Namen hat.
  • Prüfen Sie Überschriftenstruktur, Landmarken und semantisches HTML.
  • Prüfen Sie Tastaturbedienung und sichtbare Fokus-Indikatoren.
  • Finden Sie Kontrastfehler bei Text und UI-Komponenten.
  • Prüfen Sie Formularbeschriftungen, Fehlermeldungen und Hinweise.
  • Prüfen Sie Bilder, Icons und SVGs auf sinnvolle Alternativen.
  • Testen Sie korrigierte Templates und wichtige Seiten erneut.

Warum WCAG 2.2 AA das praktische Ziel ist

Die WCAG sind in Erfolgskriterien der Stufen A, AA und AAA gegliedert. Stufe A deckt die grundlegendsten Barrieren ab; Stufe AA ergänzt Anforderungen, die bei öffentlichen und kommerziellen Websites allgemein erwartet werden. WCAG 2.2 behält die bekannten Kriterien aus WCAG 2.1 bei und ergänzt neuere Anforderungen wie Fokus-Erscheinungsbild und Zielgröße.

Für Webinhalte in der EU verweist die EN 301 549 auf die WCAG-Kriterien. Ein WCAG-Audit ist damit eine praktische Grundlage für die EAA-Vorbereitung, Barrierefreiheitserklärungen und Vergabefragebögen.

Häufige WCAG-Fehler, die Konversionen kosten

Barrierefreiheitsprobleme sind nicht nur ein rechtliches Risiko; sie sind Konversionsprobleme. Fehlende Beschriftungen erschweren Formulare. Geringer Kontrast versteckt Preise und Handlungsaufforderungen. Tastaturfallen blockieren Menschen mit assistiven Technologien ebenso wie Power-User. Unklare Fehlermeldungen lassen den Checkout kaputt wirken.

Die schnellsten Verbesserungen kommen meist aus dem Designsystem: barrierefreie Buttons, Formularfelder, modale Dialoge, Navigation und Hinweis-Komponenten. Wer diese Muster korrigiert, verbessert jede Seite, die sie verwendet.

  • Buttons und Links ohne beschreibenden Namen
  • Formularfelder ohne Beschriftung oder mit unzugänglichen Fehlermeldungen
  • Modale Dialoge, die den Fokus nicht steuern
  • Kontrastfehler bei Handlungsaufforderungen und deaktivierten Zuständen
  • Icons, die als bedeutungslose Dateinamen vorgelesen werden

Ein realistischer Korrektur-Workflow

Beginnen Sie mit kritischen und schweren Verstößen auf umsatzrelevanten Seiten. Korrigieren Sie danach wiederverwendbare Templates. Führen Sie nach jedem Sprint einen Verifizierungsscan aus, damit das Team sieht, ob dieselbe Regel weiterhin auftaucht. Bewahren Sie Vorher/Nachher-Nachweise mit den Release Notes auf; sie werden nützlich, wenn Kundschaft nach Barrierefreiheitsdokumentation fragt.

FAQ

Ersetzt WCAG 2.2 die WCAG 2.1?

WCAG 2.2 baut auf WCAG 2.1 auf. Ein WCAG-2.2-AA-Audit prüft weiterhin die früheren A/AA-Kriterien und ergänzt die neuen Anforderungen der Version 2.2.

Findet axe-core jedes WCAG-Problem?

Kein automatisches Prüfwerkzeug findet alle WCAG-Probleme. Automatisierte Tests sind hervorragend für viele im Code erkennbare Fehler; Inhaltsqualität, Aufgabenlogik und einige Multimedia-Anforderungen brauchen menschliche Prüfung.

Gehören WCAG-Korrekturen den Entwicklern oder der Rechtsabteilung?

Entwickler korrigieren den Code, aber Produkt, Design und Recht müssen sich über Umfang, Formulierung der Erklärung und Risikoprioritäten einigen. Barrierefreiheit ist ein Produktqualitätsprozess, keine Checkliste einer einzelnen Person.