Referenzierte Normen
Benötigen Sie ein fundiertes technisches Audit Ihrer digitalen Produkte anhand dieser Standards?
Audit anfordernÜberblick über die Neuerungen in WCAG 2.2
Das World Wide Web Consortium hat die WCAG 2.2-Empfehlung offiziell veröffentlicht, um Lücken in der mobilen Bedienbarkeit, Tastaturinteraktion bei Sehbehinderung und kognitiven Barrierefreiheit zu schließen. Zudem wurde das Kriterium 4.1.1 (Parsing) gestrichen, da moderne Browser die HTML-Fehlerkorrektur gemäß HTML Living Standard einheitlich handhaben.
- 9 neue Erfolgskriterien eingeführt (6 auf Stufe A/AA, 3 auf Stufe AAA).
- 1 veraltetes Kriterium gestrichen (4.1.1 Parsing).
- Stärkerer Fokus auf Zeigerinteraktionen, kognitive Belastung und Sichtbarkeit von Tastaturfokus-Indikatoren.
Fokus-Erscheinungsbild & Verdeckter Fokus
Unter SC 2.4.11 (Fokus nicht verdeckt - Minimum, Stufe AA) dürfen fixierte Header oder Cookie-Banner fokussierte Elemente nicht vollständig verdecken. Unter SC 2.4.13 (Fokus-Erscheinung, Stufe AAA) muss der Fokusindikator ein Kontrastverhältnis von mindestens 3:1 gegenüber dem Hintergrund und eine Mindestkontur von 2px aufweisen.
/* Recommended CSS for WCAG 2.2 compliant focus styling */
:focus-visible {
outline: 3px solid #0284C7;
outline-offset: 2px;
scroll-margin-top: 5rem; /* Prevents sticky headers from obscuring focus */
scroll-margin-bottom: 5rem;
}Klickzielgröße (Minimum) im Frontend
Erfolgskriterium 2.5.8 (Zielgröße - Minimum, Stufe AA) verlangt für interaktive Zeigerziele eine Fläche von mindestens 24 mal 24 CSS-Pixeln, es sei denn, ein ausreichender Abstand verhindert Überlappungen mit benachbarten Elementen.
- Inline-Links im Fliesstext sind ausgenommen.
- Wesentliche Zielpunkte (wie Markierungen auf dichten interaktiven Karten) sind befreit.
- Best Practice für mobile Touch-Ziele bleibt 44x44 CSS-px (Apple) bzw. 48x48 CSS-px (Android).
Ziehbewegungen & Alternativen für Einzeiger-Bedienung
Unter SC 2.5.7 (Ziehbewegungen, Stufe AA) muss jede Funktion, die Ziehbewegungen erfordert (wie Kanban-Karten oder Slider), eine einfache Klick- oder Tipp-Alternative wie Hoch-/Runter-Schaltflächen bieten.
// Example: Pairing drag-and-drop with accessible button controls
<div role="listitem">
<span>Task Name</span>
<div className="flex gap-2">
<button aria-label="Move task up" onClick={moveUp}>↑</button>
<button aria-label="Move task down" onClick={moveDown}>↓</button>
</div>
</div>Redundante Eingaben & Barrierefreie Authentifizierung
SC 3.3.7 (Redundante Eingabe, Stufe A) untersagt die erneute Abfrage zuvor eingegebener Daten in derselben Sitzung. SC 3.3.8 (Zugängliche Authentifizierung, Stufe AA) schreibt vor, dass Logins nicht allein auf kognitiven Gedächtnistests oder visuellen CAPTCHAs basieren dürfen, ohne Alternativen wie Passwort-Manager-Autofill oder Passkeys bereitzustellen.
Technische Implementierungs-Checkliste
Nutzen Sie diese Checkliste bei Code-Reviews, um die Konformität neuer Komponenten mit WCAG 2.2 vor dem Release sicherzustellen:
- Sicherstellen, dass fixierte Banner fokussierte Elemente nicht verdecken (scroll-margin nutzen).
- Gewährleisten, dass Schaltflächen und Icons mindestens 24x24px Klickfläche besitzen.
- Tastatur- oder Button-Alternativen für Drag-and-Drop-Sortierungen bereitstellen.
- Einfügen (Paste) in allen Passwort- und Bestätigungsfeldern uneingeschränkt erlauben.
- Wiederholte Adress- und Kontaktdaten in mehrstufigen Formularen automatisch übernehmen.
TaggedWorks Engineering Research Group
Praxisgruppe für digitales Barrierefreiheits-Engineering & Forschung
TaggedWorks-Forschungspublikationen werden von praktizierenden Barrierefreiheits-Ingenieuren und Fachspezialisten verfasst. Unsere Empfehlungen basieren auf aktuellen WCAG 2.2-Interpretationen, Browser-Verhalten und Kompatibilitätstabellen assistiver Technologien.