WCAG 2.1 AA und WCAG 2.2: was sich für Shops ändert

Das Wichtigste in Kürze

• WCAG 2.2 ersetzt WCAG 2.1 nicht, sondern erweitert sie: neun neue Erfolgskriterien, davon sechs auf den relevanten Stufen A und AA. Ein Kriterium – 4.1.1 Parsing – wurde gestrichen.
• Der technische Stand, an dem sich die deutsche BFSG-Praxis bisher ausrichtet, ist WCAG 2.1 Stufe AA – über die BFSGV und die harmonisierte europäische Norm EN 301 549.
• Welche Fassung im Einzelfall verbindlich ist, ist eine Rechtsfrage. Sie beantwortet eine Anwältin oder ein Anwalt, nicht ein Prüfwerkzeug und nicht dieser Artikel.
• Die neuen Kriterien treffen Shops an drei Stellen: Bedienelemente (Größe, Ziehbewegungen), Formulare (doppelte Eingaben, Anmeldung) und Orientierung (verdeckter Fokus, konsistente Hilfe).
• Häufigster Praxisfall ist die klebende Kopfzeile, die das per Tastatur angesteuerte Element verdeckt. Wer mit der Maus arbeitet, bemerkt das nie.
• Nur ein Teil ist maschinell messbar: Die Zielgröße einer Schaltfläche lässt sich rechnen, die Konsistenz eines Hilfe-Links über zwölf Seiten nicht.
• Wer WCAG 2.1 AA sauber umsetzt, hat den größten Teil erledigt. WCAG 2.2 ist Detailarbeit – kein zweites Projekt.

BFSG, BFSGV, EN 301 549, WCAG: wie die Ebenen zusammenhängen

Die Verwirrung um „2.1 oder 2.2“ entsteht fast immer daran, dass vier Ebenen durcheinandergeraten.

Das Gesetz. Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28.06.2025. Es benennt, wer betroffen ist und was barrierefrei sein muss – es enthält aber keine einzige technische Vorgabe darüber, wie breit eine Schaltfläche zu sein hat.

Die Verordnung. Die Barrierefreiheitsstärkungsgesetz-Verordnung (BFSGV) konkretisiert die Anforderungen und knüpft an harmonisierte europäische Normen an. „Harmonisiert“ heißt: Die Norm entstand im Auftrag der EU, ihre Fundstelle wird im Amtsblatt veröffentlicht. Daran hängt der Fachbegriff der Konformitätsvermutung – dessen Reichweite juristisch zu beurteilen ist.

Die Norm. Für Websites und digitale Dienste ist das die EN 301 549. Ihr Kapitel 9 („Web“) enthält keine eigenen Anforderungen, sondern übernimmt die WCAG-Erfolgskriterien der Stufen A und AA und nummeriert sie um: Aus WCAG 1.1.1 wird Abschnitt 9.1.1.1.

Die Richtlinie. Die Web Content Accessibility Guidelines (WCAG) stammen vom World Wide Web Consortium (W3C), dem Gremium für Web-Standards. Sie sind kein Gesetz, sondern eine technische Empfehlung – weltweit die Referenz. Sie kennen drei Stufen: A (Grundlage), AA (der übliche Maßstab in Gesetzen und Normen) und AAA (weitergehende Anforderungen).

Kurz: Das Gesetz sagt „barrierefrei“, die Verordnung verweist auf die Norm, die Norm auf die WCAG. Welche Kriterien daraus im Shop-Alltag am meisten wiegen, steht in der BFSG-Checkliste für Onlineshops.

Welcher Stand gilt: 2.1 oder 2.2?

Technisch ist die Lage klar: Die bisher herangezogene Fassung der EN 301 549 baut auf WCAG 2.1 Stufe AA auf. Das ist der Stand, gegen den wir prüfen und den wir in Berichten benennen. Bei den europäischen Normungsorganisationen CEN, CENELEC und ETSI, die die EN 301 549 gemeinsam herausgeben, liegt inzwischen eine neuere Fassung der Norm vor, die WCAG 2.2 aufgreift.

Rechtlich ist die Frage, welche Fassung wann für ein konkretes Unternehmen maßgeblich ist, eine juristische Bewertung – sie hängt unter anderem davon ab, welche Fassung im Amtsblatt der EU gelistet ist. Diese Bewertung nimmt eine Anwältin oder ein Anwalt vor. Wir liefern die technische Grundlage, nicht die Auslegung.

Für die Praxis entschärft sich die Frage aus einem Grund, den man kennen sollte: WCAG 2.2 ist abwärtskompatibel angelegt. Wer 2.2 auf Stufe AA erfüllt, erfüllt damit auch 2.1 auf Stufe AA – mit der einen Ausnahme des zurückgezogenen Kriteriums 4.1.1 Parsing. Umgekehrt gilt das nicht: Wer 2.1 AA erfüllt, hat die sechs neuen A- und AA-Kriterien nicht zwangsläufig abgedeckt.

Die neun neuen Erfolgskriterien im Überblick

Sechs der neun neuen Kriterien liegen auf den Stufen A und AA, drei auf Stufe AAA. Die englischen Bezeichnungen stehen dabei, weil Prüfberichte sie im Original führen.

Auffällig ist, wovon diese Liste handelt: nicht von Bildern, Kontrasten oder Überschriften, sondern fast durchweg von Bedienung. WCAG 2.2 schließt Lücken, die vor allem Menschen mit motorischen Einschränkungen, mit Gedächtnis- oder Konzentrationsschwierigkeiten und Nutzerinnen kleiner Touchgeräte betreffen. Deshalb werden die neuen Kriterien ausgerechnet an Warenkorb, Filter und Checkout sichtbar.

Zielgröße und Ziehbewegungen: die Bedienelemente

2.5.8 Zielgröße: 24 × 24 CSS-Pixel

Ein CSS-Pixel ist nicht dasselbe wie ein Gerätepixel, sondern die Maßeinheit, in der Layouts gerechnet werden – unabhängig davon, wie fein der Bildschirm auflöst. 24 × 24 davon sind wenig: etwa die Fläche einer kleinen Symbol-Schaltfläche.

Viele Shops scheitern trotzdem daran, und zwar an denselben Stellen: Plus und Minus für die Menge im Warenkorb sind oft schmale Striche neben dem Zahlenfeld, das Schließen-Kreuz von Newsletter- und Cookie-Fenstern ein zierliches Symbol in der Ecke. Dazu kommen Bewertungssterne, die farbigen Punkte der Variantenauswahl und die Ziffern der Seitenblätterung.

Das Kriterium kennt Ausnahmen, weshalb sich der Fall nicht rein rechnerisch entscheiden lässt: Kleiner ist zulässig bei genügend Abstand zu benachbarten Zielen, wenn dieselbe Funktion auf derselben Seite ausreichend groß erreichbar ist, bei Links im Fließtext und bei Vorgaben des Browsers. Für Touchbedienung empfiehlt das W3C ohnehin mehr als dieses Minimum.

2.5.7 Ziehbewegungen: alles, was gewischt wird

Ziehen setzt voraus, dass jemand einen Punkt trifft, gedrückt hält, präzise bewegt und an der richtigen Stelle loslässt. Für Menschen mit Zittern, mit Kopfsteuerung oder mit einer Hand am Smartphone ist das eine Hürde. Das Kriterium verlangt deshalb keine Abschaffung der Wischgeste, sondern eine zweite Möglichkeit per Klick oder Tipp.

Im Shop betrifft das vier Bauteile: die Produktgalerie ohne Pfeilschaltflächen, den Preisfilter als Schieberegler ohne Eingabefeld für Zahlen, die Karte der Filialsuche und Merklisten, deren Reihenfolge per Ziehen geändert wird. Die Wischgeste ist überall willkommen – sie darf nur nicht der einzige Weg sein.

Formulare und Anmeldung: doppelte Eingaben und Captchas

3.3.7 Redundante Eingabe

Dieses Kriterium hat den unmittelbarsten Umsatzbezug: Angaben aus demselben Vorgang müssen nicht noch einmal von Hand eingegeben werden – sie werden übernommen oder zur Auswahl angeboten.

Der Standardfall ist die abweichende Lieferadresse: In vielen Shops sind Name, Straße, Hausnummer, Postleitzahl und Ort komplett neu zu tippen, obwohl sich oft nur eine Zeile unterscheidet. Dazu kommen die doppelte Abfrage der E-Mail-Adresse „zur Sicherheit“ und mehrstufige Bestellstrecken, in denen ein Schritt zurück die Eingaben verwirft. Für Menschen mit Sprachsteuerung oder Bildschirmlupe ist jede Wiederholung ein Vielfaches an Aufwand – für alle anderen ein Grund abzubrechen. Welche Stellen im Bestellablauf sonst hängen bleiben, steht in Barrierefreier Checkout: die kritischen Schritte.

3.3.8 Zugängliche Authentifizierung

Hier geht es um einen Punkt, der oft für eine Sicherheitsmaßnahme gehalten wird, aber keine ist: das Blockieren der Zwischenablage im Passwortfeld. Wer sein Passwort nicht einfügen darf, muss es aus dem Kopf oder vom Zettel abtippen. Genau das schließt das Kriterium aus: Ein Gedächtnistest darf nicht die einzige Hürde sein, das Einfügen aus einem Passwortmanager muss möglich bleiben. Nebenbei ist ein abgetipptes Passwort meist das schwächere.

Der zweite Fall sind Captchas. Verzerrte Buchstaben, Rechenaufgaben und Bilderrätsel („alle Bilder mit Ampeln“) sind kognitive Funktionstests. Als einzige Hürde erfüllen sie das Erfolgskriterium 3.3.8 nicht – ein Verbot von Captchas ist damit nicht ausgesprochen. Verlangt wird ein alternativer Weg oder ein Verfahren ohne kognitiven Test; das Wiedererkennen von Objekten bleibt zulässig.

Beides ist selten reine Redaktionsarbeit: Die Zwischenablage blockiert meist das Theme oder ein Sicherheits-Plugin. Zu benennen, wo es klemmt, ist Sache eines Prüfberichts – der Umbau gehört in den Quellcode.

Verdeckter Fokus und konsistente Hilfe

2.4.11 Fokus nicht verdeckt – der häufigste Praxisfall

Wer mit der Tastatur arbeitet, springt mit der Tabulatortaste von Bedienelement zu Bedienelement. Das angesteuerte Element ist der Fokus; ein sichtbarer Rahmen zeigt, wo man gerade ist. Verliert man ihn aus dem Blick, ist die Seite nicht mehr bedienbar – man drückt die Eingabetaste und weiß nicht, was passiert.

Genau das erzeugen klebende Kopfzeilen. Die Kopfzeile bleibt beim Blättern oben stehen; der Browser scrollt das fokussierte Element zwar in den sichtbaren Bereich – aber genau dorthin, wo die Kopfzeile liegt. Dasselbe Muster erzeugen Cookie-Leisten am unteren Rand, Chat-Fenster in der Ecke und mitfahrende „In den Warenkorb“-Leisten.

Stufe AA verlangt, dass das fokussierte Element nicht vollständig verdeckt ist; die AAA-Variante 2.4.12 verlangt, dass es gar nicht verdeckt wird. Der Selbsttest dauert Minuten: Tabulatortaste drücken und die Seite durchgehen. Verschwindet der Rahmen zwischendurch, ist der Fall klar. Weitere Selbsttests stehen in Die häufigsten Barrierefreiheits-Fehler.

3.2.6 Konsistente Hilfe

Dieses Kriterium verlangt nicht, dass es überhaupt eine Hilfe gibt. Es verlangt: Wenn eine da ist, bleibt sie am selben Ort. Gemeint sind Kontaktangaben, Telefonnummer, Kontaktformular, Chat oder FAQ – sie erscheinen auf allen Seiten in derselben relativen Reihenfolge.

Verletzt wird das meist durch gewachsene Vorlagen: Die Startseite hat einen Chat-Knopf unten rechts, die Kategorieseiten nicht; der Kontakt-Link steht in der Hauptnavigation, verschwindet aber im Checkout, wo er am dringendsten gebraucht wird. Für Menschen, die sich Abläufe merken, statt Seiten zu überfliegen, ist das jedes Mal eine neue Suche.

Gestrichen und Kür: 4.1.1 Parsing und die AAA-Kriterien

WCAG 2.2 hat als bisher einzige Fassung ein Kriterium zurückgezogen: 4.1.1 Parsing. Es verlangte sauber verschachtelten Quelltext und eindeutige IDs. Gestrichen wurde es, weil Browser und Hilfsmittel solche Fehler heute selbst ausgleichen.

Das wird gern falsch verstanden. Doppelte IDs sind nicht harmlos geworden – sie führen weiterhin dazu, dass eine Beschriftung auf das falsche Formularfeld zeigt oder eine Verknüpfung ins Leere läuft. Nur fällt das jetzt unter andere Kriterien, etwa Beschriftungen und Namen von Bedienelementen. Für einen Prüfbericht heißt das: Der Befund verschwindet nicht, er wandert.

Die drei neuen AAA-Kriterien sind schnell abgehandelt: 2.4.12 verlangt, dass der Fokus überhaupt nicht verdeckt wird, 2.4.13 stellt Anforderungen an Größe und Kontrast des Fokusrahmens selbst, 3.3.9 lässt auch das Wiedererkennen von Objekten nicht mehr als Hürde zu. Stufe AAA ist in der EN 301 549 nicht der Maßstab, und das W3C rät davon ab, sie pauschal für ganze Websites anzustreben.

Was ein Scan davon sieht – und was nicht

Die neuen Kriterien sind ein Lehrstück darüber, wo automatische Prüfung endet: Fast alle handeln von Bedienung, Absicht und Kontext.

Daraus folgt keine Entwertung der automatischen Prüfung, sondern eine Arbeitsteilung. Ein Scan findet zuverlässig die große Menge maschinell prüfbarer Verstöße – fehlende Alternativtexte, unbeschriftete Formularfelder, zu schwache Kontraste – und liefert damit die eigentliche Arbeitsliste. Die Bedienkriterien aus WCAG 2.2 kommen im manuellen Teil dazu.

Deshalb steht in jedem unserer Berichte derselbe Satz: Automatisierte Prüfung deckt die maschinell prüfbaren Kriterien ab; eine vollständige Konformitätsbewertung erfordert zusätzlich manuelle Prüfung. Wer etwas anderes behauptet – etwa ein Widget, das eine Website per Skript in Ordnung bringt –, verspricht Unmessbares.

Was das für Ihre Planung heißt

Die praktische Botschaft ist unspektakulär, und das ist die gute Nachricht: Wer heute nach WCAG 2.1 Stufe AA arbeitet, hat den weitaus größten Teil erledigt. Die sechs neuen A- und AA-Kriterien sind überwiegend Detailarbeit an Bedienelementen und Formularen – kein zweites Projekt und kein Anlass, eine laufende Umsetzung zu stoppen.

1. Zuerst die Menge. Alternativtexte, Formularbeschriftungen, Kontraste, Seitentitel, Tastaturbedienbarkeit. Diese Befunde führen unsere Prüfläufe regelmäßig an – und stammen alle schon aus WCAG 2.1.
2. Dann der Bestellvorgang. Checkout und Warenkorb kosten bei Fehlern unmittelbar Umsatz – und dort liegen die neuen Kriterien am dichtesten: Mengenschaltflächen, doppelte Adresseingabe, Anmeldung.
3. Dann die Bedienelemente insgesamt. Zielgrößen, Wischgesten mit Alternative, verdeckter Fokus. Ein Tastatur-Durchgang durch die zehn wichtigsten Seiten findet davon das meiste an einem Vormittag.
4. Zuletzt die Konsistenz. Hilfe- und Kontaktzugang auf allen Seiten an derselben Stelle – meist eine Frage der Vorlagen, nicht der einzelnen Seite.

Was nicht sinnvoll ist: auf eine endgültige Klärung der Normfassung zu warten. Keines der neuen Kriterien verlangt, etwas zurückzubauen, das nach 2.1 richtig war. Wer jetzt anfängt, arbeitet in jeder Fassung in die richtige Richtung.

Häufige Fragen

Dieser Artikel ist eine technische Einordnung und keine Rechtsberatung. Quellen: Web Content Accessibility Guidelines (WCAG) 2.1, W3C-Empfehlung vom 05.06.2018, und WCAG 2.2, W3C-Empfehlung vom 05.10.2023 (aktualisiert 12.12.2024); daraus insbesondere die Erfolgskriterien 2.4.11 Focus Not Obscured (Minimum, Stufe AA), 2.4.12 Focus Not Obscured (Enhanced, AAA), 2.4.13 Focus Appearance (AAA), 2.5.7 Dragging Movements (AA), 2.5.8 Target Size (Minimum, AA), 3.2.6 Consistent Help (A), 3.3.7 Redundant Entry (A), 3.3.8 Accessible Authentication (Minimum, AA), 3.3.9 Accessible Authentication (Enhanced, AAA) sowie das in WCAG 2.2 zurückgezogene Kriterium 4.1.1 Parsing; EN 301 549 (harmonisierte europäische Norm), Kapitel 9 „Web“; Gesetz zur Stärkung der Barrierefreiheit von Produkten und Dienstleistungen (BFSG), insbesondere §§ 3, 14 und 37; Barrierefreiheitsstärkungsgesetz-Verordnung (BFSGV).