Web Accessibility-Checkliste: WCAG 2.2 für Designer in der Praxis
Eine WCAG 2.2 Accessibility-Checkliste, organisiert nach dem Ort der Entscheidung: Figma, Browser, nach dem Launch. Plus eine Karte der häufigsten Designer-Fehler zu den WCAG-Kriterien.
Die meisten Web-Accessibility-Checklisten sind für Designer nutzlos. Sie sind nach WCAG-Erfolgskriteriennummern geordnet, so wie ein Anwalt die Spezifikation liest und wie niemand Software baut.
Designer öffnen Figma nicht und denken an Kriterium 1.4.3. Sie öffnen Figma und wählen eine Textfarbe. Eine nützliche Checkliste trifft den Designer dort, wo die Entscheidung fällt, was drei separate Listen bedeutet: eine für die Design-Datei, eine für den Browser, eine für die Zeit nach dem Launch. Jede andere Anordnung und sie wird übersprungen.
Was WCAG 2.2 tatsächlich verlangt
WCAG 2.2 ist der aktuelle globale Standard ab 2026 und fügt neun neue Erfolgskriterien auf WCAG 2.1 auf, mit Schwerpunkt auf Mobile, Touch-Targets, kognitiver Last und Authentifizierung.
Die neun neuen Kriterien, die für Designer relevant sind, bilden eine kurze Liste. Die Fokusdarstellung wird strenger (2.4.11, 2.4.13). Ziehgesten benötigen jetzt eine Alternative ohne Ziehen (2.5.7). Touch-Targets haben eine Mindestgröße von 24 mal 24 CSS-Pixeln, sofern das Target nicht genug Abstand um sich hat (2.5.8). Eine konsistente Platzierung von Hilfe auf allen Seiten ist erforderlich (3.2.6). Formulare dürfen dieselbe Information nicht unnötig zweimal abfragen (3.3.7). Authentifizierung darf sich nicht auf einen kognitiven Test wie das Erinnern eines Passworts ohne Alternative stützen (3.3.8, 3.3.9).
AA ist das Level, das die meisten Accessibility-Gesetze weltweit verlangen, darunter der European Accessibility Act der EU, Section 508 in den USA und die UK's Public Sector Bodies Accessibility Regulations. AAA ist strenger und hauptsächlich für Behörden, Gesundheitswesen und Bildung vorbehalten.
Eine nach WCAG-Abschnittsnummern geordnete Checkliste ist eine Spezifikation. Eine nach dem Arbeitsort geordnete Checkliste ist ein Werkzeug.
Das einzige Checklistenformat, das funktioniert
Accessibility wird an drei Stellen entschieden. Die Design-Datei. Die gebaute Oberfläche im Browser. Die Produktions-Website nach dem Launch.
Rund 70 % der Accessibility-Fehler sind Entscheidungen in Figma, 20 % entstehen bei der Implementierung, und 10 % sickern nach dem Launch durch Content-Änderungen, Drittanbieter-Embeds oder nutzergeneriertes Material ein. Jede Checkliste, die nicht auf diese drei Phasen abbildet, zwingt den Designer, aus der Spezifikationssprache in die Workflow-Sprache zu übersetzen, und genau bei dieser Übersetzung werden Punkte übersprungen.
Der Rest dieses Artikels besteht aus den drei Listen, in dieser Reihenfolge. Führe sie der Reihe nach durch. Was die Design-Phase-Prüfung nicht besteht, sollte die Build-Phase nie erreichen. Was die Build-Phase nicht besteht, sollte nie ausgeliefert werden.
Checkliste für die Design-Phase (was du in Figma prüfst)
Rund 70 % der Accessibility-Fehler sind Entscheidungen in der Design-Datei, was bedeutet, dass sie dort auch am günstigsten zu beheben sind.
| Prüfpunkt | WCAG 2.2 Kriterium | So prüfst du in Figma |
|---|---|---|
| Fließtext erreicht 4,5:1 Kontrast gegen den Hintergrund | 1.4.3 Contrast (Minimum) | Stark, Able oder Figmas integrierter Kontrast-Checker |
| Großer Text (18pt+ oder 14pt+ fett) erreicht 3:1 | 1.4.3 | Gleiche Tools |
| Nicht-Text-UI (Buttons, Rahmen, Icons, Fokusringe) erreicht 3:1 | 1.4.11 Non-text Contrast | Farbpaare auf der Canvas manuell prüfen |
| Touch-Targets sind mindestens 24 mal 24 CSS-px (48 mal 48 empfohlen) | 2.5.8 Target Size (Minimum) | Frame-Abmessungen direkt messen |
| Informationen werden nicht nur durch Farbe vermittelt | 1.4.1 Use of Color | Den Frame in Graustufen umwandeln (Figma-Plugin oder Screenshot-Filter) |
| Jeder Bildrahmen hat Alt-Text in den Layer-Metadaten | 1.1.1 Non-text Content | Figmas Accessibility-Panel oder Dev-Modus |
| Überschriften folgen einer logischen Reihenfolge (H1, H2, H3, nicht H1, H3, H2) | 1.3.1 Info and Relationships | Den Überschriftenbaum von oben nach unten lesen |
| Fokuszustand ist für jedes interaktive Element designt | 2.4.7 Focus Visible, 2.4.11 Focus Not Obscured | Jede interaktive Komponente hat eine Fokusvariante |
| Linktext ergibt außerhalb des Kontexts Sinn | 2.4.4 Link Purpose | Keine Labels wie „Hier klicken" oder „Mehr erfahren" |
| Formular-Labels sind sichtbar, nicht nur als Placeholder | 3.3.2 Labels or Instructions | Jedes Feld hat ein dauerhaftes Label außerhalb des Inputs |
Die Design-Datei ist auch der Ort, an dem du die neuen WCAG 2.2 Mobile-Kriterien aufdeckst. Tap-Targets, die 2.5.8 nicht bestehen, scheitern fast immer daran, dass der Designer in Desktop-Pixeln dachte und das Target ein 16-Pixel-Icon ohne Padding ist.
Für eine tiefere Auseinandersetzung mit Kontrast speziell, siehe Kontrastregeln und APCA. Die Farbarbeit in der Design-Phase ist der Punkt, an dem die meisten Sites das Audit verlieren, bevor eine Zeile Code geschrieben ist.
Checkliste für die Build-Phase (was du im Browser prüfst)
Der Browser ist der Ort, an dem Accessibility-Entscheidungen bewiesen oder entlarvt werden, weil er der erste Ort ist, an dem echte Assistenztechnologie deine Arbeit berührt.
| Prüfpunkt | WCAG 2.2 Kriterium | So prüfst du im Browser |
|---|---|---|
| Jede Seite funktioniert nur mit Tastatur (Tab, Shift-Tab, Enter, Space, Pfeiltasten) | 2.1.1 Keyboard | Maus abstecken und die Seite navigieren |
| Fokusreihenfolge folgt der visuellen Reihenfolge (links nach rechts, oben nach unten bei LTR) | 2.4.3 Focus Order | Per Tab navigieren und den Fokusring beobachten |
| Fokus wird nie durch Sticky-Header, Cookie-Banner oder Modals verborgen | 2.4.11 Focus Not Obscured (Minimum) | Beim Tabben scrollen, um die Sichtbarkeit zu bestätigen |
| Ziehinteraktionen haben eine Klick- oder Tipp-Alternative | 2.5.7 Dragging Movements | Slider, sortierbare Listen, Karussells prüfen |
| Skip-to-Content-Link erscheint beim ersten Tab | 2.4.1 Bypass Blocks | Einmal Tab nach dem Seitenladen |
| HTML-Landmarks werden verwendet (header, nav, main, footer, aside) | 1.3.1, 4.1.2 | DOM-Gliederung untersuchen |
| Formularfehler werden angekündigt, nicht nur farblich markiert | 3.3.1, 3.3.3, 4.1.3 | Ein fehlerhaftes Formular mit einem Screen Reader absenden |
| Screen Reader kündigt Überschriften, Listen und Buttons korrekt an | 4.1.2 Name, Role, Value | NVDA auf Windows, VoiceOver auf Mac, TalkBack auf Android |
| Autocomplete-Attribute sind bei persönlichen Datenfeldern gesetzt | 1.3.5 Identify Input Purpose | autocomplete bei Name-, E-Mail-, Adressfeldern prüfen |
| Medien haben Untertitel, Transkripte oder Audiobeschreibungen | 1.2.1 bis 1.2.5 | Jedes Video abspielen, auf Tracks prüfen |
Automatisierte Tools erkennen etwa 30 % davon. Den Rest braucht ein Mensch, der Tab drückt und einem Screen Reader zuhört. Beides zählt, und keines ersetzt das andere.
Das beste Browser-Tool-Stack 2026 ist klein: axe DevTools für automatisches Scanning, Lighthouse für seitenweite Audits und ein echter Screen Reader für den manuellen Durchgang. Drei Tools, zehn Minuten pro Seite, fangen fast alles ab, was ein echtes Audit beanstanden würde.
Checkliste nach dem Launch (was du in der Produktion prüfst)
Accessibility endet nicht beim Launch, weil Content, Drittanbieter-Embeds und nutzergeneriertes Material alles nach der Abnahme des Designers ausgeliefert wird.
| Prüfpunkt | WCAG 2.2 Kriterium | So prüfst du in der Produktion |
|---|---|---|
| Vom CMS erstellte Bilder haben Alt-Text, der auf Editor-Ebene erzwungen wird | 1.1.1 | CMS testen: Kann ein Autor ohne Alt-Text veröffentlichen? |
| Eingebettete Drittanbieter-Widgets (Chat, Karten, Formulare) sind zugänglich | Variiert | axe auf Seiten mit Embeds ausführen |
| PDF-Downloads und Dokumente sind getaggt und lesbar | 1.1.1, 1.3.1, 2.4.6 | In Acrobats Accessibility-Checker öffnen |
| Hilfe-, Support- und Kontaktlinks befinden sich auf jeder Seite an derselben Stelle | 3.2.6 Consistent Help (WCAG 2.2 neu) | Visuelles Audit über Templates hinweg |
| Formulare fragen in einem Flow nicht nach redundanten Informationen | 3.3.7 Redundant Entry (WCAG 2.2 neu) | Mehrstufige Formulare durchgehen |
| Authentifizierung hat eine zugängliche Alternative (Passkeys, E-Mail-Links, SSO) | 3.3.8, 3.3.9 Accessible Authentication (WCAG 2.2 neu) | Anmeldung und Login mit gesperrtem Passwort-Manager ausprobieren |
| Dynamische Inhalte (Modals, Toasts, Live-Regionen) werden angekündigt | 4.1.3 Status Messages | Jeden mit geöffnetem Screen Reader auslösen |
| Die Seite erfüllt Kontrast- und Target-Size-Regeln auch nach 200%-Zoom durch den Nutzer | 1.4.4 Resize Text, 1.4.10 Reflow | Browser auf 200% zoomen und prüfen |
| Kein automatisch abspielendes Medium oder das Medium hat eine Pause-Steuerung | 1.4.2 Audio Control, 2.2.2 Pause, Stop, Hide | Die Seite kalt laden |
| Cookie-Banner fängt Tastaturfokus nicht ein | 2.1.2 No Keyboard Trap | In das Banner tabben, wieder heraus tabben |
Die Post-Launch-Liste ist der Punkt, an dem die meisten Teams scheitern. Das Design wurde zugänglich ausgeliefert. Die CMS-Autoren füllen es mit ungetaggten PDFs, Autoplay-Videos und einem Chat-Widget mit einem 2:1-Kontrastverhältnis auf dem Launcher. Accessibility ist eine Systemeigenschaft, kein Launch-Meilenstein.
Häufige Designer-Fehler den WCAG-Kriterien zugeordnet
Jeder Befund eines Accessibility-Audits lässt sich auf ein bestimmtes WCAG-Erfolgskriterium zurückführen, und die meisten Designer machen dieselben fünf Fehler gegen dieselben fünf Kriterien.
| Designer-Fehler | Was es eigentlich ist | WCAG 2.2 Kriterium, das es verletzt |
|---|---|---|
| Placeholder-Text als einziges Label | Nutzer verlieren das Label in dem Moment, in dem sie anfangen zu tippen | 3.3.2 Labels or Instructions |
| Nur-Icon-Buttons ohne aria-label oder Tooltip | Screen Reader kündigen „button" ohne Zweck an | 4.1.2 Name, Role, Value |
| Fehlermeldungen nur mit rotem Rahmen oder rotem Text angezeigt | Nutzer mit Farbenblindheit sehen keinen Fehler | 1.4.1 Use of Color, 3.3.1 Error Identification |
| Fokusring aus ästhetischen Gründen entfernt | Tastaturnutzer sehen nicht, wo sie sich befinden | 2.4.7 Focus Visible |
| Tap-Targets unter 24 mal 24 px ohne Abstand | Mobile Nutzer tippen ständig daneben | 2.5.8 Target Size (Minimum) |
| Niedriger Kontrast bei „subtiler" UI (Placeholder-Text, deaktivierte Zustände, Hilfstext) | Leser in der Sonne oder mit Sehbehinderung können es nicht lesen | 1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast |
| Modal, das den Fokus einfängt, aber kein Schließen mit ESC hat | Tastaturnutzer stecken im Modal fest | 2.1.2 No Keyboard Trap |
| Karussells mit ausschließlich Drag-Navigation | Motorisch eingeschränkte Nutzer können nicht weiterblättern | 2.5.7 Dragging Movements |
| Sticky-Header, der das fokussierte Element beim Tabben verbirgt | Nutzer sehen, wie die Seite scrollt, verlieren aber die Position | 2.4.11 Focus Not Obscured |
| Anmeldung nur mit Passwort, kein SSO oder E-Mail-Link | Versagen bei kognitiver Last | 3.3.8 Accessible Authentication |
Dieselben zehn Fehler machen den Großteil jedes Audit-Berichts aus. Behebe sie und du bist zu 80 % auf dem Weg zu WCAG 2.2 AA, bevor irgendein Berater eine Tabelle öffnet.
Die Accessibility-Grundlagen sind auch mit dem Rest einer guten visuellen Hierarchie verbunden. Kontrast, Target-Größe und Fokuszustände sind Hierarchie-Entscheidungen. Ein Design, das Hierarchie beherrscht, beherrscht standardmäßig den Großteil der Accessibility-Checkliste, weshalb die Überschneidung zwischen guter Farbtheorie und zugänglichem Design nahezu vollständig ist.
So führst du die Checkliste durch, ohne eine Woche zu verbrennen
Die Checkliste ist nur nützlich, wenn das Durchführen Minuten, nicht Tage dauert, was bedeutet, dass Tooling den Großteil der Arbeit übernehmen muss.
Die Arbeitsabfolge umfasst drei Durchgänge, einen pro Phase, jeweils zu dem Zeitpunkt, an dem die Arbeit diese Phase erreicht. Nicht alle drei am Ende. Nicht einer davon am Ende. Drei separate Durchgänge, jeder günstig, jeder durch Tooling erzwungen, wo möglich.
- Design-Durchgang: 10 Minuten pro Screen. Stark oder Figmas Kontrast-Checker auf jedes Textpaar, den Frame in Graustufen umwandeln, um rein farbbasierte Informationen zu testen, jedes Tap-Target messen. Vor dem Handoff erledigen, nicht beim Review.
- Build-Durchgang: 10 Minuten pro Template. axe DevTools-Scan, reiner Tastatur-Navigationstest, ein Screen-Reader-Durchgang auf den meistbesuchten Seiten. axe-core in CI integrieren, damit neuer Code keine Regressionen einführen kann.
- Launch-Durchgang: monatlich, nicht pro Release. Vollständiger axe- oder pa11y-Crawl auf der Produktion, PDF-Audit auf jeder Dokumentenbibliothek, manueller Walkthrough von Formularen und Authentifizierungsflows.
Das ist ein halber Arbeitstag pro Monat pro Produkt und vielleicht 15 Minuten pro Design-Handoff. Mehr als das und das Team hört auf, es durchzuführen. Weniger und die Audits kommen unbehoben zurück.
FAQ
Ist WCAG 2.2 gesetzlich vorgeschrieben?
Ja, in den meisten großen Märkten. Der European Accessibility Act trat im Juni 2025 in Kraft und verweist auf WCAG 2.1 als Minimum, mit 2.2 als aktuellem Arbeitsstandard. Section 508 in den USA verweist auf WCAG 2.0, aber Beschaffungsverträge fordern zunehmend 2.2. Kanada, Großbritannien, Australien und Japan haben alle ähnliche Anforderungen, die an WCAG 2.1 oder 2.2 geknüpft sind. Wenn du in einen dieser Märkte lieferst, ist 2.2 AA das sichere Ziel.
Welche neuen WCAG 2.2 Kriterien muss ich wirklich kennen?
Vier sind für Designer am wichtigsten. 2.5.7 Dragging Movements verlangt eine Alternative ohne Ziehen für Ziehinteraktionen. 2.5.8 Target Size (Minimum) verlangt Tap-Targets von mindestens 24 mal 24 CSS-Pixeln mit ausreichend Abstand. 2.4.11 Focus Not Obscured verlangt, dass das fokussierte Element beim Scrollen und durch Sticky-Overlays sichtbar bleibt. 3.3.8 Accessible Authentication verbietet kognitive Tests wie das Erinnern eines Passworts ohne Alternative (SSO, Passkey oder E-Mail-Link).
Brauche ich eine separate Checkliste für Mobile?
Nein. WCAG 2.2 ist ausdrücklich geschrieben, um Mobile und Touch abzudecken, weshalb so viele der neuen Kriterien (Target-Größe, Ziehen, Fokus) mobile-bewusst sind. Dieselbe dreiphasige Checkliste funktioniert für Mobile Web und Responsive Design. Native Apps haben zusätzliche plattformspezifische Richtlinien (Apples HIG und Android Accessibility), aber die WCAG-Regeln gelten trotzdem.
Wie groß ist das Mindest-Touch-Target in WCAG 2.2?
24 mal 24 CSS-Pixel ist das Minimum unter 2.5.8 Target Size (Minimum), aber es gibt Ausnahmen, wenn Targets genug Abstand um sich haben oder inline mit Text sind. Das praktische Ziel, auf das die meisten Designer abzielen sollten, sind 48 mal 48 CSS-Pixel, was den Plattformempfehlungen von Apple und Google entspricht und die Randfälle in der WCAG-Spezifikation vermeidet.
Die Checkliste ausliefern, nicht das Rätselraten
Accessibility ist keine Compliance-Aufgabe. Es ist eine Design-Eigenschaft, die an drei Momenten aufgebaut, durch Tooling erzwungen und von Menschen geprüft wird.
Die Teams, die zugängliche Sites ohne Schmerzen ausliefern, sind nicht diejenigen mit den besten Auditoren. Es sind diejenigen, die die Prüfungen in die Design-Phase, die Build-Phase und die Launch-Phase verlagert haben und es abgelehnt haben, Arbeit mit bekannten Fehlern über eine dieser Phasen hinausgehen zu lassen.
Führe die drei Listen durch. Fange die zehn häufigen Fehler ab, bevor sie sich summieren. Automatisiere die Browser-Scans in CI. Prüfe die Post-Launch-Drift monatlich. WCAG 2.2 AA hört auf, eine Ziellinie zu sein, und wird zu einer Eigenschaft der Arbeitsweise des Teams.
Wähle heute eine Produkt-Oberfläche auf deiner Site. Führe die Design-Phase-Checkliste gegen ihre Figma-Datei durch. Zähle die Korrekturen. Diese Zahl ist der Preis dafür, sie nicht früher durchgeführt zu haben.
Die Checkliste ausliefern, nicht das Rätselraten.
Need a site that passes WCAG 2.2 without a three-month remediation cycle? Brainy ships accessible design from the first Figma frame.
Get Started
