WCAG 2.2: Die neuen Erfolgskriterien im Detail

1. Warum WCAG 2.2 kam und wie es sich zu 2.1 verhält

WCAG 2.2 ist keine Ablösung von WCAG 2.1, sondern eine additive Erweiterung: Alle Erfolgskriterien von 2.1 bleiben unverändert gültig, WCAG 2.2 fügt lediglich neue hinzu und entfernt ein einziges bestehendes Kriterium, 4.1.1 Parsing, weil es angesichts moderner Browser und robuster HTML-Parser praktisch keine eigenständige Prüfrelevanz mehr hatte. Wer bereits gegen 2.1 AA konform ist, verliert durch den Wechsel zu 2.2 also nichts, sondern bekommt neun zusätzliche Kriterien, die im Wesentlichen aus praktischer Erfahrung mit mobiler Bedienung, Authentifizierung und Fokus-Sichtbarkeit entstanden sind.

Das W3C hat die neuen Kriterien bewusst so gewählt, dass sie Lücken schließen, die sich in den Jahren seit WCAG 2.1 in der Praxis als besonders folgenreich erwiesen haben: Winzige Touch-Ziele auf Mobilgeräten, Drag-and-Drop-Interaktionen ohne Tastaturalternative, Sicherheitsabfragen, die kognitiv überfordern, und Fokusindikatoren, die von Cookie-Bannern oder Sticky-Headern verdeckt werden. Wer diese Muster im eigenen Shop wiedererkennt, sollte WCAG 2.2 nicht als bürokratische Fußnote, sondern als direkte Reaktion auf real beobachtete Barrieren verstehen.

2. Focus Not Obscured: Sichtbarer Fokus trotz Sticky-Elementen

Die Kriterien 2.4.11 Focus Not Obscured (Minimum) auf Stufe AA und 2.4.12 Focus Not Obscured (Enhanced) auf Stufe AAA verlangen, dass ein fokussiertes Element bei Tastaturnavigation nicht vollständig, beziehungsweise im Enhanced-Fall gar nicht, von anderen Inhalten verdeckt wird. In der Praxis betrifft das genau die Muster, die in modernen Shop-Frontends allgegenwärtig sind: ein sticky Header, ein Cookie-Consent-Banner am unteren Bildschirmrand oder ein fixiertes Warenkorb-Icon, das beim Durchtabben eines langen Formulars den fokussierten Button verdeckt.

Für Hyvä-Themes mit Alpine.js bedeutet das konkret, dass sticky positionierte Elemente einen ausreichenden scroll-margin oder scroll-padding-top am fokussierbaren Zielelement benötigen, damit der Browser beim Fokussieren per Tastatur automatisch so weit scrollt, dass das Element nicht unter dem Sticky-Header verschwindet. Wer testen will, ob ein Shop dieses Kriterium erfüllt, tabbt einfach konsequent durch eine lange Seite mit sticky Header und prüft, ob der blaue Fokusring an jeder Stelle mindestens teilweise sichtbar bleibt.

/* Verhindert, dass ein sticky Header den Fokusring verdeckt (WCAG 2.4.11) */
:root {
  --sticky-header-height: 4rem;
}

[tabindex], a, button, input, select, textarea {
  scroll-margin-top: calc(var(--sticky-header-height) + 0.5rem);
}

3. Dragging Movements: Alternativen zu Drag-and-Drop

Kriterium 2.5.7 Dragging Movements auf Stufe AA verlangt, dass jede Funktion, die per Ziehbewegung ausgelöst wird, auch ohne Ziehen bedienbar ist, es sei denn, das Ziehen ist für die Funktion wesentlich, etwa beim Zeichnen in einer Grafiksoftware. Für Onlineshops betrifft das vor allem Bildergalerien mit Swipe-Karussells, Mengen-Slider für die Bestellmenge oder ziehbare Range-Filter in der Kategorienavigation, wenn diese ausschließlich per Pointer-Drag bedienbar sind.

Die praktische Lösung besteht meist darin, neben der Drag-Geste eine gleichwertige Klick- oder Tastaturalternative anzubieten: Pfeiltasten-Buttons neben einem Bildkarussell, ein Texteingabefeld neben einem Mengen-Slider oder ein Klick auf einzelne Schritte einer Range statt eines reinen Ziehreglers. Wichtig ist, dass diese Alternative gleichwertig zugänglich sein muss, ein winziger, kaum sichtbarer Pfeil-Button in der Ecke eines Karussells erfüllt das Kriterium formal, aber nicht im Sinne der Norm.

4. Target Size Minimum: Mindestgröße für Bedienelemente

Kriterium 2.5.8 Target Size (Minimum) auf Stufe AA schreibt vor, dass klickbare oder antippbare Ziele mindestens 24 mal 24 CSS-Pixel groß sein müssen, sofern sie nicht durch ausreichenden Abstand zu benachbarten Zielen kompensiert werden, Teil eines Fließtextsatzes sind, oder eine gleichwertige, größere Alternative an anderer Stelle existiert. Das trifft in bestehenden Magento-Themes häufig kleine Icon-Buttons wie das Herz-Icon für die Wunschliste, das Schließen-Kreuz eines Modals oder Pagination-Pfeile, die oft deutlich unter 24 Pixel liegen.

In Tailwind-basierten Hyvä-Themes lässt sich das Kriterium meist mit einer konsequenten Mindestgröße für interaktive Icon-Elemente lösen, ohne das visuelle Design grundlegend zu verändern: Die klickbare Fläche kann größer sein als das sichtbare Icon selbst, indem Padding statt einer erzwungenen Icon-Vergrößerung genutzt wird. Dieses Muster erhält den kompakten visuellen Eindruck, vergrößert aber die tatsächliche Trefferfläche für Maus, Touch und assistive Eingabegeräte gleichermaßen.

<!-- Sichtbares Icon bleibt klein, klickbare Fläche erreicht 24x24px durch Padding -->
<button
  type="button"
  class="p-2.5 -m-2.5 inline-flex items-center justify-center rounded-full hover:bg-slate-100"
  aria-label="Zur Wunschliste hinzufügen"
>
  <svg class="w-4 h-4" aria-hidden="true"><!-- Herz-Icon --></svg>
</button>

5. Consistent Help: Hilfe-Angebote an konsistenter Position

Kriterium 3.2.6 Consistent Help auf Stufe A verlangt, dass Hilfe-Mechanismen wie ein Live-Chat, eine Kontakt-Telefonnummer oder ein Link zu häufig gestellten Fragen auf allen Seiten einer Website, auf denen sie vorkommen, an relativ konsistenter Position innerhalb der Seitenreihenfolge erscheinen. Das Kriterium verbietet nicht, dass sich das visuelle Layout zwischen Seitentypen leicht unterscheidet, verlangt aber, dass Nutzer, die einmal gelernt haben, wo Hilfe zu finden ist, dieses Muster auf anderen Seiten wiederfinden.

Für Magento-Shops betrifft das häufig genau die Stellen, an denen Hilfe am dringendsten gebraucht wird: den Checkout. Wenn der Live-Chat-Button auf der Kategorieseite unten rechts erscheint, im Checkout aber plötzlich fehlt oder an anderer Stelle auftaucht, verletzt das Kriterium 3.2.6, selbst wenn der Chat technisch einwandfrei funktioniert. Die Lösung ist meist organisatorisch statt technisch: ein einziges, global im Layout verankertes Hilfe-Element, das über Layout-XML konsistent auf allen relevanten Seiten inklusive Checkout eingebunden wird.

6. Accessible Authentication: Login ohne kognitive Rätsel

Die Kriterien 3.3.8 Accessible Authentication (Minimum) auf Stufe AA und 3.3.9 Accessible Authentication (Enhanced) auf Stufe AAA verlangen, dass ein Authentifizierungsprozess keinen kognitiven Funktionstest voraussetzt, wie das Merken eines Passworts, das Lösen eines Puzzle-Captchas oder das korrekte Umsortieren von Zeichen, es sei denn, es existiert eine alternative Methode, die diesen Test nicht erfordert, oder ein Mechanismus zur Unterstützung wie Copy-and-Paste oder ein Passwort-Manager wird nicht blockiert.

Der häufigste Verstoß in bestehenden Magento-Checkouts ist ein Login- oder Registrierungsformular, das Copy-and-Paste in Passwortfeldern per JavaScript unterbindet, angeblich aus Sicherheitsgründen, tatsächlich aber vor allem Nutzer von Passwort-Managern und Menschen mit kognitiven Einschränkungen behindert, ohne einen belastbaren Sicherheitsgewinn zu bringen. Ebenso kritisch sind Bild-Captchas ohne barrierefreie Alternative wie ein Audio-Captcha oder ein unsichtbares, verhaltensbasiertes Verfahren.

7. Redundant Entry und weitere neue Kriterien

Kriterium 3.3.7 Redundant Entry auf Stufe A verlangt, dass Informationen, die ein Nutzer bereits zuvor im selben Prozess eingegeben hat, nicht erneut manuell eingegeben werden müssen, es sei denn, es ist für die Funktion wesentlich, etwa aus Sicherheitsgründen bei einer erneuten Passworteingabe zur Bestätigung. Für einen mehrstufigen Magento-Checkout bedeutet das konkret: Wenn Rechnungs- und Lieferadresse identisch sind, muss eine Checkbox das erneute Eintippen der zweiten Adresse ersetzen können, statt beide Formulare unabhängig auszufüllen zu lassen.

Ergänzt wird die Liste durch 2.4.13 Focus Appearance auf Stufe AAA, das präzise Mindestanforderungen an Kontrast und Größe des Fokusindikators selbst definiert, über die bloße Sichtbarkeit aus 2.4.11 hinaus. Auch wenn AAA-Kriterien selten verpflichtend gefordert werden, lohnt sich ein Blick darauf, weil ein kräftiger, gut sichtbarer Fokusring ohnehin zu den einfachsten und wirkungsvollsten Maßnahmen für Tastaturnutzer gehört und sich meist mit wenigen CSS-Zeilen umsetzen lässt.

8. Praktische Auswirkung auf bestehende Magento-Checkouts

In der Summe treffen die neuen Kriterien den Checkout-Prozess überproportional stark, weil dort kleine Icon-Buttons, Live-Chat-Widgets, Login-Formulare und mehrstufige Adresseingaben aufeinandertreffen. Ein typischer Prüflauf gegen WCAG 2.2 in einem bestehenden Shop findet daher regelmäßig Verstöße gegen Target Size bei Mengen-Steppern und Entfernen-Icons im Warenkorb, gegen Accessible Authentication bei blockiertem Copy-and-Paste im Passwortfeld, und gegen Redundant Entry, wenn Gast-Checkout und Registrierung getrennt implementiert sind und Adressdaten dabei doppelt erfasst werden müssen.

Positiv formuliert bedeutet das: Wer diese vier bis fünf konkreten Muster gezielt behebt, deckt den Großteil der praktischen Auswirkung von WCAG 2.2 auf einen typischen Magento-Shop bereits ab, ohne eine vollständige Frontend-Überarbeitung zu benötigen. Die übrigen Kriterien wie Consistent Help und Dragging Movements betreffen meist einzelne, klar abgrenzbare Komponenten wie den Hilfe-Link im Footer oder ein Bilderkarussell auf der Produktdetailseite.

9. Migrationscheckliste für bestehende WCAG-2.1-Shops

Für einen strukturierten Umstieg empfiehlt sich eine Checkliste, die genau die neun neuen Kriterien einzeln abarbeitet, statt einen kompletten Neu-Audit gegen alle Kriterien durchzuführen, da die 2.1-Basis ja bereits geprüft ist. Schritt eins ist ein konsequentes Durchtabben aller Formulare inklusive Checkout, um Focus-Not-Obscured-Verstöße durch sticky Elemente zu finden. Schritt zwei ist ein visueller Scan aller Icon-Buttons mit einem Browser-Overlay-Tool, das Klickflächen unter 24 Pixel farblich markiert.

Schritt drei prüft Login- und Registrierungsformulare auf blockiertes Copy-and-Paste sowie auf Captcha-Alternativen, Schritt vier den Checkout-Flow auf doppelte Adresseingaben, und Schritt fünf sucht nach Drag-only-Interaktionen in Bildergalerien und Slidern. Abschließend lohnt sich ein Seitenvergleich zwischen Kategorieseite, Produktdetailseite und Checkout, um zu prüfen, ob Hilfe-Elemente wie Chat oder FAQ-Link tatsächlich an konsistenter Position erscheinen, wie es Consistent Help verlangt.

10. Zusammenfassung

11. FAQ: WCAG 2.2: Das Wichtigste auf einen Blick