WCAG 2.2 verändert, wie Sie Webprojekte gestalten. Neun neue Erfolgskriterien betreffen direkt Fokus-Indikatoren, Klickflächen und Login-Flows. Das sind Kernbereiche jedes modernen Interface-Designs. Wer diese Anforderungen erst beim Code-Review prüft, macht Barrierefreiheit im Web zur teuren Nacharbeit. Teams, die Barrierefreiheit als Qualitätsmerkmal begreifen, integrieren die neuen Kriterien früh im Designprozess und produzieren robustere Interfaces.
Was hat sich mit WCAG 2.2 für Designprojekte verändert?
WCAG 2.2 baut auf den bestehenden Richtlinien auf. Die neuen Kriterien adressieren vor allem mobile Nutzung, kognitive Barrierefreiheit und Tastaturzugänglichkeit. Für Designteams bedeutet das eine klare Verschiebung. Mehr Anforderungen liegen jetzt im Verantwortungsbereich des Designs, nicht allein in der Entwicklung.
Welche neuen Kriterien betreffen das UI direkt?
Teilen Sie die neun neuen Erfolgskriterien gedanklich in zwei Gruppen. Die erste löst der Code, die zweite muss das Design lösen. Designrelevant sind Focus Not Obscured (2.4.11), Focus Appearance (2.4.13) und Target Size Minimum (2.5.8). Hinzu kommen Consistent Help (3.2.6), Redundant Entry (3.3.7) und Accessible Authentication (3.3.8). Dragging Movements (2.5.7) liegt an der Schnittstelle beider Disziplinen, weil Sie für jede Ziehinteraktion eine barrierefreie Alternative anbieten müssen.
Was entfällt, was bleibt?
WCAG 2.2 streicht das Kriterium 4.1.1 Parsing. Es hatte in der Praxis kaum noch Relevanz. Moderne Browser gehen mit fehlerhaften HTML-Strukturen robust um. Alle anderen Kriterien aus WCAG 2.1 bleiben bestehen. Sie erweitern also Ihren bisherigen Prozess, ohne ihn grundlegend zu ersetzen.
Wie lösen Sie Fokus-Sichtbarkeit gestalterisch?
Fokus-Indikatoren sind in vielen Design-Systemen ein Nachgedanke. WCAG 2.2 macht sie zur expliziten Anforderung. Focus Not Obscured (2.4.11) fordert, dass ein fokussiertes Element nicht vollständig durch andere Inhalte verdeckt wird. Focus Appearance (2.4.13) geht weiter und definiert Mindestanforderungen an Größe und Kontrast des Fokus-Rahmens.
Warum sind Fokus-Indikatoren keine Schönheitsfrage?
Tastaturnutzer, Screen-Reader-Nutzer und Menschen mit motorischen Einschränkungen navigieren Oberflächen über den Fokus. Ist dieser unsichtbar oder verdeckt, verlieren sie die Orientierung auf der Seite. Sticky Header, modale Overlays und Fixed-Position-Elemente sind die häufigsten Ursachen für verdeckte Fokus-Zustände.
Wie sieht ein barrierefreier Fokus-Indikator konkret aus?
WCAG 2.4.13 definiert konkrete Mindestmaße. Der Fokus-Umriss muss einen mindestens 2 CSS-Pixel breiten Rahmen erzeugen. Zudem verlangt die Norm einen Kontrast von mindestens 3:1 zwischen fokussiertem und unfokussiertem Zustand. Definieren Sie Fokus-Stile als Teil Ihres UX/UI-Design-Systems als explizite Design-Token, nicht als Browser-Default. Ein Fokus-Rahmen in Ihrer Brand-Farbe mit ausreichend Kontrast erfüllt die Anforderung und wirkt gestalterisch konsistent. Details zur vollständigen Spezifikation liefert die W3C-Dokumentation zu Focus Appearance.
Wie dimensionieren Sie Klickflächen richtig?
Target Size Minimum (2.5.8) gilt auf Stufe AA. Es fordert, dass interaktive Elemente mindestens 24 × 24 CSS-Pixel groß sind. Alternativ genügt ausreichend Abstand zu benachbarten Elementen. Das klingt nach einer kleinen Anforderung, trifft aber überraschend viele gängige Interface-Muster.
Wo unterschreiten Interfaces die Mindestgröße am häufigsten?
Icon-only-Buttons in Toolbars, schließbare Tags in Filterlisten, kleine Checkbox-Labels und Inline-Textlinks in engem Zeilenabstand scheitern regelmäßig an 2.5.8. Auch Paginierungs-Links und Social-Icons in Footern sind typische Problemstellen. Das Problem liegt selten am sichtbaren Element selbst, sondern daran, dass sein Trefferbereich zu klein dimensioniert ist.
Wie setzen Sie Target Size in der Praxis um?
Vergrößern Sie nicht das sichtbare Element, sondern seinen Trefferbereich über Padding oder transparente Pseudo-Elemente. So bleibt das visuelle Design intakt und Sie erfüllen die Anforderung. Wer barrierefreies Webdesign konsequent umsetzt, verankert diese Regel als festen Bestandteil jedes interaktiven Elements. Ein Komponentensystem, das Web Accessibility von Anfang an mitdenkt, spart sich kostspielige Korrekturen.
Wie gestalten Sie Authentifizierung ohne kognitive Hürden?
Accessible Authentication (3.3.8) verbietet Authentifizierungsmechanismen, die einen kognitiven Funktionstest erfordern. Gemeint sind zum Beispiel verzerrter Text oder ein Bild-Rätsel. Das Kriterium gilt auf Stufe AA und betrifft jeden Login-Flow, der mehr verlangt als das Eingeben von Zugangsdaten.
Warum scheitern kognitive Tests in Login-Masken?
Text-CAPTCHAs und Bild-Rätsel sind für viele Menschen mit kognitiven Beeinträchtigungen, Lernschwierigkeiten oder eingeschränkter Sehleistung nicht lösbar. Sie schützen zwar vor automatisierten Zugriffen, schließen aber gleichzeitig echte Nutzer aus. WCAG 2.2 fordert nicht, auf Authentifizierung zu verzichten, sondern auf die kognitive Hürde.
Welche Alternativen zur CAPTCHA gibt es?
Magic Links per E-Mail, geräteseitige Authentifizierung über WebAuthn und biometrische Verfahren erfüllen WCAG 3.3.8 und schützen zuverlässig vor Bots. Stellen Sie sicher, dass Eingabefelder keine autocomplete-Attribute unterdrücken. Nutzer müssen ihren Passwort-Manager frei einsetzen können. Copy-Paste-Sperren in Passwortfeldern sind damit nicht mehr zulässig.
Konsistente Hilfe und redundante Eingaben
Consistent Help (3.2.6) fordert, dass Hilfe-Mechanismen, die auf mehreren Seiten erscheinen, immer an derselben relativen Position stehen. Redundant Entry (3.3.7) verlangt, dass Nutzer bereits eingegebene Informationen nicht erneut eingeben müssen, sofern keine klare Notwendigkeit dafür besteht.
Was steckt hinter konsistenter Hilfe?
Konsistente Hilfe heißt nicht, dass jede Seite ein Hilfe-Element braucht. Bieten Sie Hilfe an, etwa einen Chat, eine Telefonnummer oder einen FAQ-Link, erscheint dieser immer an derselben Stelle. Nutzer mit kognitiven Einschränkungen verlassen sich darauf, Hilfe dort zu finden, wo sie sie zuletzt gesehen haben. Das ist eine Layout-Entscheidung, keine Entwicklungsaufgabe.
Wie vermeiden Sie Redundant Entry gestalterisch?
Benötigt ein mehrstufiges Formular Informationen aus einem früheren Schritt, haben Sie drei Möglichkeiten. Zeigen Sie die Information vor dem Feld an, übertragen Sie sie automatisch oder lassen Sie Nutzer die Angabe bestätigen. Besonders bei Checkout-Prozessen, Onboarding-Flows und Antragsformularen entsteht hier unnötiger Aufwand. Wer dieses Prinzip von Anfang an in seine Komponenten einbaut, spart sich aufwendige Nacharbeit bei der Barrierefreiheitsprüfung.
Fazit
WCAG 2.2 stellt mehr Anforderungen ans Design als jede Vorgängerversion. Fokus-Indikatoren, Klickflächen, Login-Flows und Hilfe-Elemente sind keine Randthemen, sondern Kernfragen moderner Interface-Gestaltung. Wer diese Kriterien früh im Prozess berücksichtigt, produziert bessere Interfaces und vermeidet kostspielige Nacharbeit.
Sie möchten wissen, wie Sie WCAG 2.2 konkret in Ihrem nächsten Projekt umsetzen? Sprechen Sie uns an. Wir analysieren Ihren aktuellen Stand und zeigen Ihnen, wo und wie Sie am effektivsten ansetzen. Vereinbaren Sie jetzt Ihr kostenloses Erstgespräch.
