Wie testen Sie Ihre Website gegen die Richtlinien von WCAG 2.2?

Es steckt eine Person hinter jedem Klick, Scrollen und Tippen, und sie versuchen, etwas zu erledigen. Für einige hilft das Web ihnen nicht immer, sich auf halbem Weg zu treffen. Dies ist kein Fehler bei den Menschen; es ist ein Fehler darin, wie wir Websites erstellen.

WCAG 2.2 steht kurz davor, das zu ändern. Mit der Veröffentlichung von WCAG 2.2 führen wir noch mehr Updates ein, um die Bedürfnisse noch mehr Nutzer des Webs besser widerzuspiegeln. Wir haben Änderungen für Menschen mit Sehbehinderungen, Gedächtnis- oder Aufmerksamkeitsproblemen und solche, die Touchgeräte verwenden, hinzugefügt.

Hier erfahren Sie, wie Sie Ihre Website sorgfältig, klar und selbstbewusst gegen WCAG 2.2 testen können!

Die Grundlagen von WCAG 2.2 verstehen

Wenn Sie Ihre Website barrierefrei machen möchten, müssen Sie die Richtlinien verstehen, gegen die Sie testen.

Die Richtlinien für barrierefreie Webinhalte (WCAG) sind die Standards, die Sie und Ihre Entwickler zu erfüllen versuchen, um Menschen mit allen Arten von Fähigkeiten die Nutzung Ihrer digitalen Inhalte zu ermöglichen.

WCAG hat drei Ebenen von Richtlinien:

• Ebene A - die grundlegendsten Anforderungen. Websites, die A nicht bestehen, sind in der Regel so unbrauchbar, dass sie einige Menschen frustrieren, die versuchen, sie überhaupt zu nutzen.
• Ebene AA - der am häufigsten verwendete Standard. Ebene AA bewertet das Gleichgewicht zwischen Benutzerfreundlichkeit und Praktikabilität und ist in vielen Ländern häufig eine gesetzliche Anforderung.
• Ebene AAA - die höchste Ebene, die Sie erreichen können. Es wäre ideal, aber nicht jede Website oder Person wird es erreichen können.

WCAG 2.2 hat neun Erfolgskriterien für insgesamt 78 hinzugefügt und ist ein Nachtrag zu WCAG 2.1 und wird insbesondere die Erfahrung für Personen mit kognitiven Beeinträchtigungen, Sehbehinderungen und solchen, die Touchgeräte verwenden, verbessern.

Neue Erfolgskriterien von WCAG 2.2

Das Web sollte ein Bereich sein, in dem sich die Menschen nicht verloren, ausgeschlossen oder zurückgelassen fühlen. Die neuen Erfolgskriterien in WCAG 2.2 sollen kleinere, bedeutungsvolle Probleme angehen, mit denen echte Menschen jeden Tag konfrontiert sind.

Lassen Sie uns alle neun davon betrachten, nicht nur als Regeln, sondern als menschliche Erfahrungen.

Erfolgskriterium	Name	Ebene
2.4.11	Fokuserscheinung (Minimum)	AA
2.4.12	Fokus nicht verdeckt (Minimum)	AA
2.4.13	Fokus nicht verdeckt (Erweitert)	AAA
2.5.7	Ziehbewegungen	AA
2.5.8	Zielgröße (Minimum)	AA
3.2.6	Konsistente Hilfe	AAA

Was ist der Unterschied zwischen WCAG 2.1 und WCAG 2.2?

Als WCAG 2.1 veröffentlicht wurde, schloss es wichtige Lücken für Menschen, die mobile Geräte nutzen, für Menschen mit Sehbehinderungen sowie für Menschen mit kognitiven Beeinträchtigungen. Es war ein wichtiger Fortschritt.

WCAG 2.2 führt diesen Fortschritt fort. Es ersetzt WCAG 2.1 nicht, sondern baut darauf auf. Wenn Sie also bereits die Standards von WCAG 2.1 erfüllen, sind Sie fast am Ziel.

Allerdings bringt WCAG 2.2 neun neue Erfolgskriterien mit, um das Web noch benutzerfreundlicher zu machen – insbesondere für Menschen, die in der digitalen Welt oft übersehen werden.

Kurz gesagt:
Der Unterschied zwischen WCAG 2.1 und WCAG 2.2 liegt in den zusätzlichen Erfolgskriterien, die den Zugang und die Nutzung für bestimmte Nutzergruppen weiter verbessern.
 

WCAG 2.1	WCAG 2.2
Veröffentlicht im Jahr 2018	Veröffentlicht im Jahr 2023
Ergänzte 17 Erfolgskriterien zu WCAG 2.0	Ergänzt 9 neue Erfolgskriterien zu WCAG 2.1
Fokus auf mobile Barrierefreiheit, Sehbehinderungen und kognitive Beeinträchtigungen	Vertieft die Unterstützung für dieselben Nutzergruppen mit noch gezielterer Anleitung
Konformität auf Level AA wird von vielen Gesetzen gefordert	WCAG 2.2 ist noch nicht überall gesetzlich vorgeschrieben, zeigt aber bei Umsetzung ein starkes Bekenntnis zu Best Practices

Vorbereitung auf das Testen

Bevor Sie mit dem Testen Ihrer Website auf WCAG 2.2-Konformität beginnen, sollten Sie Geduld mitbringen und Ihre Schritte sorgfältig planen.

So bereiten Sie sich klug und strukturiert vor:

1. Erstellen Sie einen Testplan

Ein Testplan hilft Ihnen dabei:

• Klare Ziele festzulegen (z. B.: „Das Ziel ist, WCAG 2.2 Level AA zu erfüllen“)
• Zu definieren, welche Tools und Verfahren Sie verwenden
• Die beteiligten Personen zu bestimmen (Entwickler, QA, Designer, Texter, Barrierefreiheitsberater)

2. Bestimmen Sie, welche Seiten und Komponenten getestet werden

Nicht jede Seite Ihrer Website muss in gleicher Tiefe getestet werden. Es gibt jedoch einige Bereiche, auf die Sie sich besonders konzentrieren sollten, z. B.:

• Startseite
• Navigationsmenüs
• Formulare (Kontakt, Checkout, Login)
• Interaktive Elemente (Buttons, Slider, Akkordeons)
• Dynamische Inhalte (Pop-ins/Pop-ups, Modals, Fehlermeldungen, Warnhinweise usw.)

Beginnen Sie mit den Bereichen, mit denen Ihre Nutzer am häufigsten interagieren. Hier liegen oft die größten Risiken in Bezug auf Barrierefreiheit.

3. Lernen Sie Ihre Nutzer kennen

Es ist wichtig zu wissen, wer Ihre Nutzer sind und wie sie mit Ihren Inhalten interagieren:

• Screenreader-Nutzer, die den Bildschirm nicht sehen können
• Nutzer, die nur mit der Tastatur navigieren, da sie keine Maus verwenden können
• Nutzer mit kognitiven Beeinträchtigungen, die Klarheit und Einfachheit benötigen
• Nutzer auf mobilen Geräten, die größere Klickflächen und weniger visuelle Unordnung brauchen

Je besser Sie Ihre Zielgruppe kennen, desto sinnvoller wird Ihr Testprozess.

4. Erstellen Sie eine Ausgangsbasis mit WCAG 2.1 (falls noch nicht geschehen)

Falls Sie Ihre Website noch nicht nach WCAG 2.1 getestet haben, sollten Sie dies zuerst tun. Die meisten Kriterien von 2.2 bauen direkt auf denen von 2.1 auf.
Wenn Sie WCAG 2.1 Level AA erreichen, erfüllen Sie bereits viele der wichtigsten Anforderungen und haben einen deutlich einfacheren Weg zu WCAG 2.2.

Testen Sie Ihre Website auf WCAG 2.2-Richtlinien in drei Schritten

Um die Einhaltung der WCAG 2.2 auf Ihrer Website zu messen, sollten Sie eine Kombination aus automatisierten Tools, manuellen Überprüfungen und Tests mit echten Nutzern verwenden.
Jede dieser Methoden deckt unterschiedliche Barrierefreiheitsprobleme auf.

1. Automatisierte Test-Tools

Automatisierte Tools eignen sich hervorragend, um häufige Barrierefreiheitsprobleme schnell zu identifizieren.
Sie analysieren Ihre Website und melden Fehler wie fehlenden Alternativtext, fehlerhafte Überschriftenstruktur oder Probleme mit dem Farbkontrast.

Vorteile:

• Schnell und einfach auszuführen
• Erkennt viele technische Fehler
• Gut geeignet für kontinuierliche Überprüfungen

Einschränkungen:

• Bewertet keinen Nutzungskontext oder die User Experience
• Erkennt keine Probleme bei der Tastaturnavigation oder unklare Linkbeschriftungen

Empfehlungen:

• Axe DevTools – Browser-Erweiterung mit klaren Berichten
• WAVE – Visuelles Tool, das Barrierefreiheitsfehler und Warnungen direkt hervorhebt
• Lighthouse – In Chrome DevTools integriert, bietet umfassende Accessibility-Audits

2. Manuelles Testen

Manuelles Testen schließt die Lücken, die automatisierte Tests offenlassen, und erlaubt es, die tatsächliche Nutzung durch Anwender zu bewerten – ob mit Hilfstechnologien, Maus oder nur mit der Tastatur.

Wichtige Prüfpunkte:

• Tastaturnavigation – Alle Elemente müssen erreichbar und in einer sinnvollen Tab-Reihenfolge nutzbar sein.
• Fokus-Indikatoren – Deutliche visuelle Hervorhebung beim Navigieren durch Elemente.
• Screenreader-Kompatibilität – Testen mit NVDA, VoiceOver oder JAWS.
• Farbkontrast & visuelle Hinweise – Inhalte müssen auch ohne Farbe als alleinige Kennzeichnung verständlich sein.
• Touch-Ziele – Buttons und Links gemäß den WCAG 2.2-Vorgaben zu Größe anpassen.
• Konsistente Navigation – Menüs, Header und Layout sollten ein erkennbares Muster aufweisen.
• Neue WCAG 2.2-Kriterien – Manuell prüfen, z. B. Focus Appearance and Dragging Movements.

3. Testen mit echten Nutzern

Tests mit Menschen, die Hilfstechnologien nutzen oder mit Behinderungen leben, liefern das realistischste Bild der tatsächlichen Nutzbarkeit Ihrer Website.

Warum es wichtig ist:

• Deckt Barrieren auf, die weder automatisierte Tools noch manuelle Tests erfassen
• Liefert eine praxisnahe Überprüfung Ihrer Barrierefreiheitsmaßnahmen

So gehen Sie vor:

• Teilnehmer mit verschiedenen Behinderungen und technischen Vorlieben einbeziehen
• Einheitliche Aufgaben definieren (z. B. Formular ausfüllen, Navigation testen)
• Interaktionen beobachten, um Reibungspunkte zu erkennen
• Feedback zu Verständlichkeit, Komfort und Benutzerfreundlichkeit einholen
• Ergebnisse mit technischen Audit-Daten kombinieren, um ein vollständiges Bild zu erhalten

Probleme und Lösungen dokumentieren

Barrierefreiheitsprobleme zu finden, ist nur der erste Schritt – das Nachverfolgen und Beheben ist die eigentliche Arbeit.

Alle Probleme erfassen

Wie in jedem Schritt Ihres Accessibility-Testprozesses sollten Sie jedes identifizierte Problem dokumentieren.
Jeder Eintrag sollte enthalten:

• Eine kurze Beschreibung
• Die betroffene Seite oder das Element
• Das zugehörige WCAG 2.2-Kriterium
• Die Schwere des Problems

Eine vollständige Dokumentation hält Ihr Team fokussiert und stellt sicher, dass keine kritischen Punkte übersehen werden.

Checkliste verwenden

Eine WCAG-Checkliste macht den Prozess übersichtlicher.
Sie hilft Ihnen, festzuhalten:

• Was bereits getestet wurde
• Was noch geprüft werden muss

Während Sie die Website durchgehen, können Sie bei jeder Richtlinie angeben: Bestanden, Nicht bestanden oder Nicht zutreffend.
Das schafft Struktur – besonders, wenn mehrere Personen gleichzeitig testen.

Gemeinsam Probleme lösen

Barrierefreiheitsprobleme werden selten allein behoben:

• Entwickler beheben Codeprobleme
• Designer optimieren Layout und Kontraste
• Texter & Content-Editoren verbessern die Verständlichkeit von Texten, Labels, Überschriften u. v. m.

Gemeinsames Arbeiten macht den Prozess effizienter und zielgerichteter.

Behobene Probleme erneut testen

Sobald ein Problem behoben ist, sollten Sie es erneut testen.
So stellen Sie sicher, dass:

• Das ursprüngliche Problem tatsächlich gelöst wurde
• Keine neuen Probleme entstanden sind

Nachtests geben Ihnen Sicherheit, dass Sie langfristige Verbesserungen in der Barrierefreiheit erzielt haben.

Fazit

Das Testen nach WCAG 2.2 stellt sicher, dass Ihre Website für alle funktioniert, auch für Menschen, die Hilfstechnologien nutzen oder die Welt auf andere Weise wahrnehmen.

Accessibility-Tests erfordern eine Mischung aus Tools, sorgfältigen manuellen Prüfungen und echtem Nutzerfeedback. Das kann anfangs überwältigend wirken – aber kleine Schritte sind immer besser als gar keine.

Unsicher, wo Sie anfangen sollen?
Starten Sie mit einem kostenlosen Accessibility-Audit für Ihre Website mit Accesstive.
So erhalten Sie wertvolle Einblicke darüber, was gut ist, wo Probleme liegen und wie Sie ein inklusiveres Web-Erlebnis schaffen können – inklusive kostenlosem Audit-Downloadbericht.