Sechs WCAG-2.2-Lücken schliessen: Checkliste für Entwickler:innen mit Tests und Lösungen

WCAG 2.2 ist die aktuelle W3C Recommendation. Konformität auf Stufe AA bedeutet, dass Sie jedes Erfolgskriterium der Stufen A und AA erfüllen, darunter sechs der neun neu hinzugekommenen (2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 und 3.3.8). Beginnen Sie mit einer automatisierten Prüfung, um die bekannten Probleme auf Stufe A und AA zu bereinigen. Testen Sie danach die neuen verhaltensbezogenen Kriterien manuell, denn die meisten davon erkennt kein Crawler.

---

Kurz zusammengefasst:

• Sechs der neun neuen WCAG-2.2-Kriterien sind für die Konformität auf Stufe AA erforderlich. Sie betreffen die Sichtbarkeit des Fokus, Alternativen zu Ziehbewegungen, die Zielgrösse, die Platzierung von Hilfe, die Anmeldung und mehrfache Eingaben.

• Automatisierte Werkzeuge decken über die Hälfte der bestehenden WCAG-2.1-Probleme ab. Für verhaltensbezogene Kriterien wie die Erkennbarkeit des Fokus oder die Zugänglichkeit von Ziehbewegungen sind manuelle Tests aber unverzichtbar.

• Zum Testen gehören sowohl schnelle automatisierte Prüfungen struktureller Probleme als auch manuelle Kontrollen mit Tastatur, Screenreader und Auge auf ausgewählten Seiten, nach einer klar definierten Methodik.

• Der Wechsel von WCAG 2.1 auf 2.2 verlangt im Wesentlichen die Umsetzung von sechs neuen AA-Kriterien, dazu kommen drei optionale AAA-Kriterien. Für bereits konforme Websites ist der Übergang damit gut zu bewältigen.

• Eine klare und präzise Dokumentation von Geltungsbereich, Testmethodik und geprüften Seiten ist für vertragliche Zusagen und Konformitätsaussagen entscheidend, besonders wenn Sie sich auf eine bestimmte WCAG-Version und Stufe berufen.

---

Was ist an der WCAG-2.2-Checkliste wirklich neu?

WCAG 2.2 ersetzt WCAG 2.1 nicht, sondern baut darauf auf. Jedes Erfolgskriterium aus 2.1 bleibt unverändert bestehen, mit Ausnahme eines Kriteriums, das ganz entfernt wurde (dazu später mehr). Dazu kommen neun neue Erfolgskriterien. Je nachdem, wie man gruppierte Kriterien zählt, ergibt das insgesamt 86 oder 87 Erfolgskriterien über die Stufen A, AA und AAA.

Die neun Ergänzungen sind nicht zufällig gewählt. Sie zielen auf drei Gruppen, die in der Barrierefreiheit bisher zu kurz kamen: Menschen mit motorischen Einschränkungen, die mit kleinen Klickzielen und Ziehbewegungen kämpfen, Menschen mit kognitiven Beeinträchtigungen, die in mehrstufigen Abläufen den Überblick verlieren, und Menschen mit eingeschränktem Sehvermögen, die eine gleichbleibende, vorhersehbare Navigation brauchen. Wenn Ihr letztes Audit auf WCAG 2.1 aufgebaut war, schliessen Sie genau diese Lücke.

Für die Konformitätsarbeit zählt vor allem diese Aufteilung:

• Sechs neue Kriterien gehören zur Stufe A oder AA und sind für die AA-Konformität erforderlich: Focus Not Obscured (Minimum) 2.4.11, Dragging Movements 2.5.7, Target Size (Minimum) 2.5.8, Consistent Help 3.2.6, Accessible Authentication (Minimum) 3.3.7 und Redundant Entry 3.3.8.

• Drei gelten nur für AAA. Sie sind damit empfehlenswert, aber für die übliche AA-Konformität nicht erforderlich: Focus Not Obscured (Enhanced) 2.4.12, Focus Appearance 2.4.13 und Accessible Authentication (Enhanced) 3.3.9.

• Ein älteres Kriterium wurde gestrichen: 4.1.1 Parsing gilt nicht mehr, weil moderne Browser fehlerhaftes Markup so verarbeiten, dass der ursprüngliche Test hinfällig wurde.

Wenn Sie eine Checkliste für eine Kundin, einen Kunden oder ein internes Audit erstellen, lautet die praktische Erkenntnis: Gewichten Sie nicht alle neun neuen Punkte gleich. Sechs davon entscheiden, ob Sie AA erreichen. Die anderen drei sind ein zusätzliches Ziel.

Die neun neuen WCAG-2.2-Erfolgskriterien, je ein Test

Das ist die Arbeitscheckliste. Zu jedem Punkt gehört ein kurzer Test, den Sie selbst durchführen können, plus die Lösung, die ihn in der Regel erfüllt. Sechs davon sind für AA erforderlich, drei gehören zu AAA und sind entsprechend gekennzeichnet.

1. 2.4.11 Focus Not Obscured (Minimum), AA. Test: Springen Sie mit der Tabulatortaste durch jedes interaktive Element der Seite und prüfen Sie, ob eine fixierte Kopfzeile, ein Cookie-Banner oder ein Chat-Fenster das fokussierte Element je vollständig verdeckt. Lösung: Ergänzen Sie in CSS scroll-margin-top oder scroll-padding-top, damit fokussierte Elemente unterhalb fixierter Kopfzeilen frei bleiben, und setzen Sie einen tieferen z-index oder blenden Sie Überlagerungen bei Fokus aus.

2. 2.5.7 Dragging Movements, AA. Test: Suchen Sie jede Funktion, die auf Ziehen beruht (Schieberegler, Umsortieren per Drag-and-drop, Verschieben von Karten), und stellen Sie sicher, dass jede davon auch mit einem einzelnen Klick oder Tippen funktioniert. Lösung: Ergänzen Sie neben Schiebereglern klare Schaltflächen für auf/ab oder links/rechts, oder ein Menü «an Position verschieben» als Alternative zum Umsortieren per Ziehen.

3. 2.5.8 Target Size (Minimum), AA. Test: Messen Sie klickbare Ziele, die keine Textlinks im Fliesstext sind. Alles unter 24 mal 24 CSS-Pixel fällt durch, sofern nicht genügend Abstand zu benachbarten Zielen oder eine gleich grosse unsichtbare Trefferfläche vorhanden ist. Lösung: Versehen Sie kleine Icon-Schaltflächen per CSS mit Innenabstand (padding oder ein grösseres min-width/min-height), statt das sichtbare Symbol zu verkleinern.

4. 3.2.6 Consistent Help, AA. Test: Wenn eine Hilfefunktion (Chat-Link, Kontaktangaben, Hilfeseite) auf mehr als einer Seite vorhanden ist, prüfen Sie, ob sie auf allen Seiten an derselben relativen Position in der Navigationsreihenfolge erscheint. Lösung: Platzieren Sie Hilfe-Links in einer gemeinsamen Kopf- oder Fusszeilenkomponente, statt sie pro Seite von Hand zu setzen.

5. 3.3.7 Accessible Authentication (Minimum), AA. Test: Versuchen Sie, sich ausschliesslich mit einem Passwortmanager und der automatischen Ausfüllfunktion des Browsers anzumelden. Wenn das Formular das Einfügen blockiert, autocomplete-Attribute entfernt oder ein manuelles Rätsel im Stil eines CAPTCHA ohne Alternative erzwingt, fällt es durch. Lösung: Lassen Sie autocomplete="current-password" und ähnliche Attribute intakt, erlauben Sie das Einfügen in Passwortfelder und bieten Sie mindestens eine Anmeldemethode an, die kein kognitives Rätsel voraussetzt.

6. 3.3.8 Redundant Entry, AA. Test: Gehen Sie jedes mehrstufige Formular durch und prüfen Sie, ob bereits eingegebene Angaben (Name, Adresse, E-Mail) erneut abgefragt werden, ohne vorausgefüllt zu sein. Lösung: Führen Sie die Formulardaten über alle Schritte hinweg im State oder im Session Storage mit und füllen Sie wiederkehrende Felder automatisch aus.

7. 2.4.12 Focus Appearance, AAA. Test: Prüfen Sie, ob die Fokusanzeige bei jeder Komponente ausreichend Kontrast und Grösse gegenüber ihrem Hintergrund hat. Lösung: Verwenden Sie eine sichtbare Umrandung von mindestens 2 CSS-Pixeln Stärke mit starkem Kontrast zu den angrenzenden Farben.

8. 2.4.13 Focus Not Obscured (Enhanced), AAA. Test: gleich wie bei 2.4.11, aber strenger: Kein Teil des fokussierten Elements darf verdeckt sein, auch nicht teilweise. Lösung: dieselben Massnahmen wie bei 2.4.11, nur konsequenter angewendet.

9. 3.3.9 Accessible Authentication (Enhanced), AAA. Test: Stellen Sie sicher, dass die Anmeldung nie verlangt, Informationen zu merken, abzuschreiben oder aus dem Gedächtnis abzurufen (keine Schritte nach dem Muster «Tippen Sie die Zeichen ein, die Sie sich gemerkt haben»). Lösung: Setzen Sie vollständig auf eine Anmeldung, die Einfügen und automatisches Ausfüllen erlaubt und keinen Schritt mit Gedächtnisleistung enthält.

Profitipp: Die Zielgrösse (2.5.8) bringt mehr Teams ins Straucheln als jedes andere neue Kriterium, weil vor Jahren aufgebaute Designsysteme oft 20px grosse Icon-Schaltflächen als Standard verwendeten. Lassen Sie ein kurzes Skript laufen, das jedes button, jedes a und jedes klickbare div auf Ihrer Website gegen die 24px-Untergrenze misst, noch bevor Ihre manuelle Prüfung beginnt. Das spart Stunden.

Die übernommene Checkliste bereinigen, bevor Sie Konformität beanspruchen

Bevor Sie überhaupt an die neun neuen Kriterien denken, muss der Rückstand aus WCAG 2.1 bereinigt sein. Das ist jener Teil der WCAG 2.2 checklist, den automatisierte Werkzeuge gut abdecken, und zugleich jener Teil, an dem Teams scheitern, die eine grüne Prüfung für das Ende der Arbeit halten.

Automatisierte Prüfwerkzeuge sind für eine bestimmte Kategorie von Problemen zuverlässig: fehlende alt-Attribute, nicht beschriftete Formularfelder, fehlende Verknüpfungen zwischen Beschriftung und Feld, zu geringer Farbkontrast bei statischem Text, fehlende Sprachangaben im Dokument und doppelte IDs. Lassen Sie zuerst ein Prüfwerkzeug über Ihre gesamte Website laufen, und Sie bereinigen in einem Nachmittag meist 50 bis 70 Prozent aller gefundenen Probleme.

Was die Automatisierung durchgehend übersieht, ist alles, was Urteilsvermögen verlangt. Beschreibt der Alternativtext das Bild tatsächlich, oder ist er einfach vorhanden? Entspricht die Tabulatorreihenfolge der visuellen Lesereihenfolge, oder springt sie so umher, dass es nur eine Person bemerkt? Ist die Überschriftenstruktur logisch, oder springt sie von H2 direkt auf H4, weil jemand nach Schriftgrösse statt nach semantischer Ebene ausgewählt hat? Dafür braucht es einen Menschen, der sich mit Tastatur und Screenreader durchklickt.

Automatisierte Werkzeuge finden rein mengenmässig einen beachtlichen Anteil der Probleme. Die meisten Ergänzungen in WCAG 2.2 verlangen aber eine manuelle Überprüfung, gerade weil sie Verhalten prüfen und nicht Markup. Ein Prüfwerkzeug kann Ihnen sagen, dass eine Schaltfläche existiert. Es kann Ihnen nicht sagen, ob Ziehen die einzige Möglichkeit ist, sie zu bedienen.

Für die Priorisierung gehen Sie in dieser Reihenfolge vor:

• Zuerst die Blockierer beheben: alles, was das Erledigen einer Aufgabe vollständig verhindert, etwa ein nicht beschriftetes Pflichtfeld oder eine Tastaturfalle.

• Danach die viel besuchten Seiten: Ihre Startseite, der Bestellablauf und die wichtigsten Konversionspfade wiegen schwerer als eine selten besuchte Archivseite.

• Kontrast- und Beschriftungsprobleme gesammelt beheben: Diese sind meist systemisch bedingt (eine falsche CSS-Variable, ein Komponenten-Template), sodass eine Korrektur Dutzende Fälle erledigt.

• Kosmetische AAA-Extras zuletzt: Eine verbesserte Fokusanzeige und ähnliche AAA-Punkte lohnen sich, aber nicht auf Kosten von AA-Blockierern.

Ein typischer Rückstand nach einem ersten Durchgang sieht so aus: 40 fehlende alt-Attribute, 12 nicht beschriftete Eingabefelder, 8 Textstellen mit zu wenig Kontrast, 3 Tastaturfallen und eine Handvoll Verstösse gegen die Überschriftenreihenfolge. Nichts davon ist neu in WCAG 2.2. Es ist schlicht die Grundlage, die stehen muss, bevor sich das Prüfen der neun neuen Kriterien lohnt.

Welcher Testablauf funktioniert bei WCAG 2.2 wirklich?

Zuerst automatisiert prüfen, dann manuell testen, immer in dieser Reihenfolge. Wer sie umdreht, verliert Stunden mit Problemen, die ein Prüfwerkzeug in Sekunden gefunden hätte.

1. Automatisierter Durchgang. Lassen Sie ein Prüfwerkzeug wie axe-core über jedes Template und jeden Seitentyp laufen (nicht über jede einzelne Seite, Templates wiederholen sich). Das bereinigt Alternativtexte, Beschriftungen und Kontraste rasch und liefert Ihnen einen Ausgangswert an Problemen.

2. Manueller Durchgang mit kleinem Werkzeugkasten. Eine Tastatur, die Entwicklerwerkzeuge des Browsers, ein Kontrastmesser, ein Passwortmanager und ein Screenreader decken fast alles ab, was die Automatisierung übersieht. Springen Sie mit der Tabulatortaste durch jeden interaktiven Ablauf. Prüfen Sie die Sichtbarkeit des Fokus gegenüber fixierten Kopfzeilen. Testen Sie Ziehbewegungen nur mit der Tastatur. Versuchen Sie, sich mit automatischem Ausfüllen und Einfügen anzumelden.

3. Stichprobenbasiertes Website-Audit nach WCAG-EM. Testen Sie bei einer ganzen Website nicht jede Seite. Das fünfstufige Verfahren von WCAG-EM legt den Geltungsbereich fest, erkundet die Struktur der Website, wählt eine repräsentative Stichprobe aus (Templates, Formulare, viel besuchte Seiten und Sonderfälle wie Fehlerzustände), prüft diese Stichprobe automatisiert und manuell und berichtet die Ergebnisse zu den einzelnen Erfolgskriterien mit bestanden/nicht bestanden und Belegen.

Ihr Werkzeugkasten muss weder teuer noch exotisch sein:

• Der eingebaute Zugänglichkeitsinspektor eines Browsers (Chrome DevTools, Firefox Accessibility Panel) für Fokusreihenfolge und ARIA-Attribute.

• Ein Kontrastprüfer für die Fokussichtbarkeit nach 2.4.11 und 2.4.13.

• Der Screenreader Ihres tatsächlichen Betriebssystems (VoiceOver, NVDA), statt sich nur auf automatisierte Ausgaben zu verlassen.

• Ein Passwortmanager, denn bei 3.3.7 geht es genau darum, ob automatisches Ausfüllen und Einfügen wirklich funktionieren.

Ihr Bericht sollte festhalten, welche Seiten oder Templates geprüft wurden, welche Erfolgskriterien getestet wurden, pro Kriterium bestanden oder nicht bestanden, und genügend Belege (ein Screenshot, eine konkrete URL, ein Schritt zur Reproduktion), damit eine andere Person Ihren Befund überprüfen kann, ohne das ganze Audit zu wiederholen.

Wie unterscheidet sich WCAG 2.2 in der Praxis von WCAG 2.1?

Wenn Ihre Website bereits WCAG 2.1 AA erfüllt, ist der Schritt zu 2.2 kleiner, als es klingt. Das ändert sich für Teams bei diesem Wechsel tatsächlich:

• 4.1.1 Parsing ist weggefallen. Das Kriterium verlangte gültiges, wohlgeformtes Markup, damit Hilfstechnologien es korrekt auswerten können. Moderne Browser und Hilfstechnologien verarbeiten fehlerhaftes HTML inzwischen so einheitlich, dass das Kriterium überflüssig wurde. Es wurde deshalb gestrichen statt übernommen.

• Sechs neue AA-Kriterien gelten, und zwar jene aus der Checkliste oben: Sichtbarkeit des Fokus, Alternativen zu Ziehbewegungen, Zielgrösse, einheitliche Platzierung von Hilfe, zugängliche Anmeldung und mehrfache Eingaben.

• Drei neue AAA-Kriterien kommen dazu, sind für übliche AA-Konformitätsaussagen aber nicht erforderlich, sofern Ihr Vertrag oder Ihr regulatorisches Umfeld nicht ausdrücklich AAA verlangt.

Für ein Team, das bereits 2.1 AA erfüllt, umfasst die Arbeit realistischerweise ein fokussiertes Projekt für die sechs neuen AA-Kriterien, nicht ein vollständiges neues Audit. Planen Sie das Budget entsprechend und prüfen Sie, ob Ihr Vertrag oder Ihre gesetzliche Pflicht ausdrücklich 2.1 oder 2.2 nennt, denn Ausnahmen und erforderlicher Umfang unterscheiden sich zwischen den Versionen leicht.

Wie sollten Sie WCAG 2.2 in Verträgen und Konformitätsunterlagen nennen?

Vage Formulierungen wie «erfüllt WCAG» sind ein Risiko, keine Konformitätsaussage. Die Empfehlung des W3C zum Verweis auf WCAG 2.2 rät, die genaue Konformitätsstufe zu nennen: «Stufe AA» bedeutet jedes Erfolgskriterium der Stufen A und AA, ohne Ausnahmen und ohne Teilpunkte. Techniques-Dokumente sind informativ, nicht normativ. Zitieren Sie eine Technik deshalb nicht so, als wäre sie eine Anforderung.

Für Schweizer Organisationen nennt der massgebende Standard der öffentlichen Hand, eCH-0059, derzeit WCAG 2.1 Stufe AA als verbindliche Grundlage für Websites der Bundesverwaltung. Eine Website des Bundes ist heute also rechtlich nicht verpflichtet, WCAG 2.2 zu erfüllen. Fachleute empfehlen dennoch, gleich nach 2.2 zu bauen, denn der Standard entwickelt sich in diese Richtung, und ein späteres Nachrüsten kostet mehr, als es jetzt gleich richtig zu machen.

Wenn Sie Anforderungen in einen Vertrag oder eine Ausschreibung schreiben, ersparen Ihnen ein paar Gewohnheiten spätere Streitigkeiten:

• Nennen Sie Version und Stufe genau («WCAG 2.2 Stufe AA»), nie nur «WCAG-konform» oder «barrierefrei».

• Listen Sie die konkreten Seiten, Templates oder Abläufe auf, für welche die Konformitätsaussage gilt. Eine Aussage für die ganze Website ohne definierten Geltungsbereich lässt sich nicht durchsetzen.

• Halten Sie fest, ob AAA-Kriterien dazugehören oder ausdrücklich ausgeschlossen sind.

• Nennen Sie die verwendete Testmethodik (automatisiertes Werkzeug, manueller Durchgang, Stichprobengrösse), damit die Aussage später überprüfbar bleibt.

Dokumentieren Sie Geltungsbereich und geprüfte Seiten Ihres Audits auf die gleiche Weise. So steht hinter einer angefochtenen Aussage eine belastbare Spur statt eines Marketingsatzes.

Wer steht hinter dieser Checkliste?

Diesen Leitfaden hat Davide Morotti verfasst. Er stützt sich auf praktische Arbeit an der Barrierefreiheit in Kundenprojekten eines Zürcher Software-Studios, das Websites, Anwendungen und Plattformen für Start-ups wie für etablierte Teams baut.

Ein paar Punkte, die nützlich sind, wenn Sie entscheiden, ob Sie dieser Checkliste vertrauen oder die Arbeit abgeben wollen:

• Das Studio hat Projekte mit Blick auf Barrierefreiheit umgesetzt, unter anderem für Arthouse Kinos, die Zürcher Kinogruppe, wo mehrstufige Ticketkäufe Tests mit Tastatur und Screenreader standhalten mussten.

• Die Arbeit für Repa Immobiliare umfasste massgeschneiderte, teilweise offline nutzbare Software. In einem solchen Umfeld genügt eine automatisierte Prüfung allein nicht, und das manuelle Testen von Sonderfällen wiegt schwerer.

• Ebenso hat das Studio grosse Systeme für Die Mitte gebaut und betreut, mit über 600 Websites einer Schweizer Partei auf einer einzigen Plattform. Zum Kundenkreis zählen zudem die UBS und die Stadt Lugano.

• Projekte werden von der ersten Beratung bis zur Übergabe durchgehend von erfahrenen Entwickler:innen geführt. So gehen Anforderungen an die Barrierefreiheit zwischen Designübergabe und Umsetzung nicht verloren.

Wie Ampersand Labs WCAG-2.2-Massnahmen angeht

Sie können diese Checkliste ohne Weiteres selbst abarbeiten, wenn Sie die Zeit haben und jemand aus der Entwicklung die Verantwortung übernimmt. Wenn Sie die Arbeit lieber jemandem übergeben, der das schon gemacht hat: Manche Studios führen Audits im Stil von WCAG-EM durch und liefern einen klar abgegrenzten Bericht mit Stichproben und einer nach Priorität geordneten Liste offener Punkte, statt eines rohen Exports aus dem Prüfwerkzeug, den Sie selbst deuten müssen.

Ein typisches Mandat beginnt damit, den Geltungsbereich festzulegen (welche Seiten, welche Abläufe, welche Konformitätsstufe), repräsentative Templates auszuwählen, die oben beschriebenen automatisierten und manuellen Durchgänge auszuführen und einen Bericht zurückzugeben, der nach Wirkung geordnet ist statt einer flachen Liste mit Hunderten von Punkten. Wenn Projekte vom ersten Gespräch bis zur Lieferung von erfahrenen Entwickler:innen geführt werden, werden Korrekturen gleich beim ersten Mal richtig umgesetzt, statt zwischen der Absicht im Design und der Auslegung in der Entwicklung hin und her zu pendeln, ein häufiger Schwachpunkt, wenn Barrierefreiheit stückweise bearbeitet wird.

Wenn die Behebung bedeutet, Komponenten neu zu bauen statt sie zu flicken, fällt diese Arbeit unter die Entwicklungsdienstleistungen von Ampersand Labs. Für Teams, die vor einer Zusage zuerst Klarheit über die Kosten brauchen, sind die aktuellen Ansätze und Mandatsformen auf der Preisseite von Ampersand Labs aufgeführt. Wenn Ihre Lücke bei der Barrierefreiheit eigentlich ein Symptom einer grösseren Altlast im Code ist, lohnt sich ein Gespräch, bevor Sie Budget in das Flicken eines Systems stecken, das ohnehin ersetzt gehört.

Quellen

Lesen Sie den normativen Text direkt in der W3C WCAG 2.2 Recommendation, statt sich auf Zusammenfassungen aus zweiter Hand zu verlassen, denn Techniken und Ausnahmen sind in Grenzfällen entscheidend. Das ACT Rules Format beschreibt, wie automatisierte Testumsetzungen gegen den Standard validiert werden, nützlich, wenn Sie beurteilen wollen, ob den Ergebnissen Ihres Prüfwerkzeugs zu trauen ist. Für den Aufbau eines Audits über eine ganze Website ist WCAG-EM 1.0 die Methodik, auf die sich Prüfende berufen, wenn eine Kundin fragt, wie die Stichprobe zustande kam. Und für eine praktische Testanleitung Kriterium für Kriterium, speziell rund um die neun Ergänzungen, ist der Testleitfaden von wcag22aa.org die direkteste Ergänzung zur obigen Checkliste.

Für Teams, die vor der eigentlichen Arbeit an der Barrierefreiheit prüfen wollen, ob ihre Website überhaupt crawlbar ist, kann ein Werkzeug wie BabyLoveGrowth’s crawlability audit grundlegende Zugriffsprobleme aufzeigen, die man zuerst ausschliessen sollte.

• W3C Recommendation

• WCAG 2.2 checklist

Häufige Fragen

Was sind die WCAG-2.2-Standards?

WCAG 2.2 ist die W3C Recommendation, die Erfolgskriterien für die Barrierefreiheit im Web auf drei Stufen festlegt: A, AA und AAA. Sie übernimmt jedes Kriterium aus WCAG 2.1 bis auf 4.1.1 Parsing, das gestrichen wurde, und ergänzt neun neue Kriterien für motorische und kognitive Bedürfnisse sowie für Menschen mit eingeschränktem Sehvermögen.

Ist WCAG 2.2 verbindlich?

WCAG 2.2 selbst ist kein Gesetz, sondern ein technischer Standard, auf den Gesetze und Verordnungen verweisen. In der Schweiz nennt der Standard der öffentlichen Hand eCH-0059 derzeit WCAG 2.1 Stufe AA als Grundlage, nicht 2.2. Dennoch wird breit empfohlen, schon jetzt auf 2.2 zu setzen, damit die Konformitätsarbeit zukunftssicher bleibt.

Was ist eine WCAG-Prüfung?

Eine WCAG-Prüfung ist ein Test gegen ein bestimmtes Erfolgskriterium, der bestanden oder nicht bestanden ergibt. Sie erfolgt über automatisierte Prüfungen für strukturelle Probleme (fehlende Beschriftungen, Kontrastverhältnisse) und über manuelle Tests für verhaltensbezogene Probleme (Bedienbarkeit per Tastatur, Sichtbarkeit des Fokus, Alternativen zu Ziehbewegungen). Eine vollständige Prüfung folgt in der Regel der WCAG-EM-Methodik: Geltungsbereich festlegen, Seiten als Stichprobe auswählen, prüfen und berichten.

Welche neuen WCAG-Standards kamen mit Version 2.2 dazu?

WCAG 2.2 hat neun Erfolgskriterien ergänzt, sechs davon sind für die Konformität auf Stufe AA erforderlich: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), Consistent Help, Accessible Authentication (Minimum) und Redundant Entry. Die übrigen drei, Focus Not Obscured (Enhanced), Focus Appearance und Accessible Authentication (Enhanced), gehören zur Stufe AAA und sind für die übliche AA-Konformität optional.

Wie lange dauert ein WCAG-2.2-Audit üblicherweise?

Das hängt von der Grösse der Website ab und davon, wie weit der Rückstand aus WCAG 2.1 bereits bereinigt ist. Ein fokussiertes Audit der sechs neuen AA-Kriterien auf einer Website, die 2.1 AA bereits erfüllt, ist in der Regel ein kurzes, klar abgegrenztes Projekt und kein kompletter Neuaufbau. Ein umfassendes erstes Audit mit automatisierter Prüfung, manuellen Tests und einem Stichprobenplan nach WCAG-EM dauert länger und wächst mit der Zahl der unterschiedlichen Templates und Nutzerabläufe auf der Website.

Empfohlen

• NeuroMynds: Die Website einer Gründerin schnell, sicher und bereit für Abonnent:innen gemacht.

• Die Mitte: Über 600 Websites einer Schweizer Partei aus einem System betreiben.

• MVP-, Web- und Mobile-App-Entwicklung in Zürich