# WCAG-2.2-AA-Checkliste für SaaS-Produkte und Web-Apps

<https://www.fixreports.com/de/blog/wcag-2-2-checklist-saas-web-apps>

Aktualisiert am 2026-10-26

Ein SaaS-Produkt hat zwei Flächen, auf denen es um Barrierefreiheit geht: die Marketing-Website, die es verkauft, und die Anwendung, die Menschen jeden Tag nutzen. Die Marketing-Website scheitert an denselben Stellen wie jede Website, mit zu geringem Kontrast, fehlenden Alternativtexten und Formularen ohne Label. Die Anwendung bringt eigene Probleme mit: Login-Abläufe, die Passwortmanager blockieren, Dialoge, die den Tastaturfokus einsperren, Single-Page-Navigation, die Screenreader nicht bemerken, Datentabellen und Diagramme ohne Text, Drag-and-drop ohne Alternative und Sitzungen, die ohne Vorwarnung ablaufen. Diese Checkliste geht WCAG 2.2 Stufe AA anhand der Bestandteile eines typischen SaaS-Produkts durch.

**Das Wichtigste in Kürze**

- WCAG 2.2 wurde im Oktober 2023 zur W3C-Empfehlung und hat neun Erfolgskriterien hinzugefügt, sechs davon auf Stufe A oder AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA) bedeutet, dass ein Login nicht davon abhängen darf, sich ein Passwort zu merken oder es abzutippen, es sei denn, man kann es einfügen oder einen Passwortmanager nutzen ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- Interaktive Ziele müssen mindestens 24 × 24 CSS-Pixel groß sein oder genug Abstand zu anderen Zielen haben (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Meldungen wie „Gespeichert“ oder „3 Ergebnisse“ müssen Screenreader erreichen, ohne den Fokus zu verschieben (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- Käufer aus der Wirtschaft und dem öffentlichen Sektor verlangen oft einen Accessibility Conformance Report, der meist auf der VPAT-Vorlage des Information Technology Industry Council erstellt wird ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## Warum ist Barrierefreiheit für SaaS wichtiger als für eine reine Präsentationswebsite?

Menschen nutzen ein SaaS-Produkt stundenlang, oft weil ihr Arbeitgeber es ausgewählt hat. Eine Barriere auf einer Marketingseite kostet einen Besucher; eine Barriere im Produkt kann jemanden daran hindern, seine Arbeit zu erledigen. Deshalb fragen größere Kunden, Hochschulen und öffentliche Stellen immer häufiger vor dem Kauf nach Barrierefreiheit, und deshalb muss die Antwort die Anwendung abdecken, nicht nur die Website.

Es ist auch deshalb wichtig, weil automatisierte Tests nur einen Teil des Problems erfassen. Tools wie axe-core finden Fehler im Markup, etwa fehlende Labels und zu geringen Kontrast. Sie können nicht beurteilen, ob ein Dialog den Fokus an die richtige Stelle zurückgibt, ob die Daten eines Diagramms als Text verfügbar sind oder ob sich ein Arbeitsablauf mit der Tastatur abschließen lässt. Eine Anwendung braucht sowohl automatisierte Prüfungen als auch manuelle Tests.

## Wie machen Sie Registrierung und Login barrierefrei?

Bei der Authentifizierung hat WCAG 2.2 die für SaaS wichtigste neue Anforderung ergänzt.

- **Erlauben Sie Einfügen und Passwortmanager (3.3.8, AA).** Blockieren Sie das Einfügen in Passwort- oder Codefelder nicht, und verwenden Sie `autocomplete="username"`, `autocomplete="current-password"` und `autocomplete="one-time-code"`, damit Browser und Passwortmanager die Felder ausfüllen können.
- **Vermeiden Sie Rätsel als einzigen Zugang.** Ein CAPTCHA, bei dem man verzerrten Text abtippen oder ein Rätsel lösen muss, ist ein Test kognitiver Funktionen. Bieten Sie eine Alternative an, und bevorzugen Sie Prüfungen, die keine Aktion der Nutzer erfordern ([W3C](https://www.w3.org/TR/turingtest/)).
- **Beschriften Sie jedes Feld (1.3.1 und 3.3.2, A).** Verwenden Sie ein sichtbares `<label>`, das mit seinem Eingabefeld verbunden ist; Platzhaltertext verschwindet, sobald jemand tippt, und ist kein Label.
- **Benennen Sie Fehler im Text (3.3.1, A) und schlagen Sie Korrekturen vor (3.3.3, AA).** „Das Passwort muss mindestens 12 Zeichen haben“ hilft; ein roter Rahmen allein hilft nicht.
- **Fragen Sie nicht zweimal (3.3.7, A).** Hat eine mehrstufige Registrierung bereits nach Firmenname oder Adresse gefragt, füllen Sie diese Angaben aus oder lassen Sie sie auswählen, statt sie erneut eintippen zu lassen.
- **Halten Sie Hilfe an derselben Stelle (3.2.6, A).** Wenn Sie Chat, einen Hilfe-Link oder Kontaktdaten anbieten, platzieren Sie sie auf jeder Seite des Ablaufs an derselben relativen Position.

## Welche Formular- und Fehlermuster verursachen die meisten Fehler?

In Formularen steckt der größte Teil der Fehler in Anwendungen. Die WebAIM-Erhebung 2026 über eine Million Startseiten fand auf 51 % davon fehlende Formular-Labels ([WebAIM](https://webaim.org/projects/million/)), und Anwendungen haben weit mehr Formulare als Startseiten.

- Geben Sie jedem Eingabefeld einen programmatisch ermittelbaren Namen, und gruppieren Sie zusammengehörige Bedienelemente wie Radiobuttons mit `<fieldset>` und `<legend>`.
- Weisen Sie dort auf Fehler hin, wo man sie bemerkt: Verschieben Sie den Fokus auf eine Fehlerübersicht am Anfang des Formulars oder auf das erste ungültige Feld, und verlinken Sie jeden Eintrag der Übersicht mit seinem Feld.
- Kennzeichnen Sie Pflichtfelder im Text, nicht nur durch Farbe (1.4.1, A).
- Senden Sie nichts ab und wechseln Sie nicht den Kontext, nur weil jemand eine Option auswählt (3.2.2, A); warten Sie auf eine ausdrückliche Aktion.

## Wie sollten sich Dialoge, Menüs und Popovers verhalten?

Bei eigenen Komponenten bricht die Unterstützung für Tastatur und Screenreader am häufigsten weg. Der WAI-ARIA Authoring Practices Guide beschreibt das erwartete Verhalten für jedes Muster ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **Dialoge**: Verschieben Sie den Fokus beim Öffnen in den Dialog, halten Sie Tab darin, solange er offen ist, schließen Sie ihn mit Escape, und geben Sie den Fokus an das Bedienelement zurück, das ihn geöffnet hat. Verwenden Sie das native `<dialog>`-Element oder `role="dialog"` mit `aria-modal="true"` und einem Namen.
- **Keine Tastaturfallen (2.1.2, A)**: Jede Komponente muss sich mit der Tastatur wieder verlassen lassen.
- **Sichtbarer Fokus (2.4.7, AA)**, der nicht hinter fixierten Headern, Cookie-Bannern oder Chat-Widgets verborgen ist (2.4.11, AA, neu in 2.2).
- **Tooltips und Popovers (1.4.13, AA)**, die sich mit Escape schließen lassen, nicht verschwinden, wenn man mit der Maus darüberfährt, und bestehen bleiben, bis sie geschlossen werden.
- **Tastenkürzel mit einer einzelnen Taste (2.1.4, A)**: Wenn das Drücken einer Buchstabentaste eine Aktion auslöst, lassen Sie die Kürzel abschalten oder neu belegen, oder machen Sie sie nur aktiv, wenn die betreffende Komponente den Fokus hat.

## Wie gehen Sie mit der Navigation in einer Single-Page-App um?

In einer Single-Page-App ändert sich die URL, ohne dass eine Seite geladen wird, daher sagen Screenreader möglicherweise nicht an, dass etwas passiert ist.

- Aktualisieren Sie bei jedem Routenwechsel den Dokumenttitel, damit jede Ansicht einen aussagekräftigen Titel hat (2.4.2, A).
- Verschieben Sie den Fokus auf die Hauptüberschrift der neuen Ansicht oder sagen Sie den Wechsel in einer höflichen Live-Region an; Frameworks wie Next.js enthalten dafür einen Route Announcer.
- Halten Sie eine logische Fokusreihenfolge ein (2.4.3, A): Nach dem Löschen eines Eintrags sollte der Fokus auf ein sinnvolles Nachbarelement gehen, nicht zurück an den Anfang der Seite.
- Bieten Sie eine Möglichkeit, wiederholte Navigation zu überspringen (2.4.1, A), etwa einen Skip-Link oder Landmarks.

## Wie machen Sie Dashboards, Datentabellen und Diagramme barrierefrei?

- **Tabellen**: Verwenden Sie echtes `<table>`-Markup mit `<th>` und `scope` für Kopfzellen sowie eine Tabellenbeschriftung (1.3.1, A). Raster aus `<div>`-Elementen brauchen das vollständige ARIA-Grid-Muster, das viel schwerer richtig umzusetzen ist.
- **Diagramme**: Geben Sie jedem Diagramm eine Textalternative, die die Kernaussage nennt, und bieten Sie die Daten als Tabelle an (1.1.1, A). Unterscheiden Sie Datenreihen nicht allein durch Farbe (1.4.1, A); ergänzen Sie Beschriftungen oder Muster.
- **Kontrast**: Text braucht 4.5:1 (1.4.3, AA), und Diagrammlinien, Icons und Rahmen von Eingabefeldern brauchen 3:1 gegenüber ihrem Hintergrund (1.4.11, AA). Prüfen Sie den Dark Mode separat. Unser [Farbkontrast-Check](/de/color-contrast-checker) testet jedes beliebige Farbpaar.
- **Statusmeldungen (4.1.3, AA)**: „Gespeichert“, „Upload abgeschlossen“ und Ergebniszahlen sollten `role="status"` oder eine Live-Region nutzen, damit Screenreader-Nutzer sie hören, ohne ihre Position zu verlieren.

## Was ändern die neuen Kriterien von WCAG 2.2 für Web-Apps?

| Kriterium | Stufe | Was es in einer App bedeutet |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Fixierte Werkzeugleisten, Banner und Chat-Widgets dürfen das fokussierte Element nicht vollständig verdecken |
| 2.5.7 Dragging Movements | AA | Alles, was per Ziehen erledigt wird, etwa das Umsortieren eines Kanban-Boards, braucht eine Alternative mit einem einzelnen Zeiger, zum Beispiel ein Menü oder Schaltflächen für nach oben und nach unten |
| 2.5.8 Target Size (Minimum) | AA | Buttons und Links mindestens 24 × 24 CSS-Pixel groß oder so weit voneinander entfernt, dass sich ein Kreis von 24 Pixeln um jedes Ziel nicht mit einem anderen überschneidet |
| 3.2.6 Consistent Help | A | Hilfe-Links, Chat und Kontaktdaten auf jeder Seite an derselben relativen Stelle |
| 3.3.7 Redundant Entry | A | Bereits im selben Prozess eingegebene Informationen werden ausgefüllt oder sind auswählbar |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login ohne Auswendiglernen oder Abtippen, es sei denn, Einfügen, Passwortmanager oder eine andere Methode sind möglich |

WCAG 2.2 hat außerdem 4.1.1 Parsing gestrichen, das keine praktische Auswirkung auf die Barrierefreiheit mehr hat ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## Was ist mit Timeouts, Layout und Zoom?

- **Sitzungs-Timeouts (2.2.1, A)**: Warnen Sie Nutzer, bevor eine Sitzung abläuft, und lassen Sie sie die Sitzung mit einer einfachen Aktion verlängern, es sei denn, das Zeitlimit ist unerlässlich oder länger als 20 Stunden. Wer laufende Arbeit zwischenspeichert, vermeidet den schlimmsten Fall.
- **Reflow (1.4.10, AA)**: Inhalte müssen bei 320 CSS-Pixeln Breite funktionieren (das entspricht einem Zoom auf 400 % auf einem 1280 Pixel breiten Bildschirm), ohne dass in zwei Richtungen gescrollt werden muss; Datentabellen und ähnliche Inhalte sind ausgenommen.
- **Textabstände (1.4.12, AA)**: Größere Zeilenhöhe und größere Buchstabenabstände dürfen keinen Text abschneiden, was Container mit fester Höhe oft tun.
- **Ausrichtung (1.3.4, AA)**: Sperren Sie die App nicht auf Hoch- oder Querformat, es sei denn, das ist unerlässlich.

## Was ist ein ACR, und brauchen Sie einen?

Ein Accessibility Conformance Report (ACR) dokumentiert, wie ein Produkt jedes Kriterium der Barrierefreiheit erfüllt: unterstützt, teilweise unterstützt oder nicht unterstützt, jeweils mit Anmerkungen. Die meisten werden auf der VPAT-Vorlage erstellt, die das Information Technology Industry Council veröffentlicht und die es in Ausgaben für WCAG, die US-Standards nach Section 508 und die europäische Norm EN 301 549 gibt ([ITI](https://www.itic.org/policy/accessibility/vpat)).

US-Bundesbehörden müssen nach Section 508 barrierefreie Technologie beschaffen ([Section508.gov](https://www.section508.gov/)), und öffentliche Stellen in der EU beziehen sich auf EN 301 549, daher werden B2B-Produkte, die an solche Kunden verkaufen, im Beschaffungsprozess oft nach einem ACR gefragt. Ein ehrlicher ACR, in dem bekannte Lücken aufgeführt sind, ist für Käufer nützlicher als einer, der volle Unterstützung behauptet. Er sollte auf Tests des Produkts beruhen, einschließlich manueller Tests; ein automatisierter Scan allein kann ihn nicht ausfüllen.

Wenn Sie in der EU an Verbraucher verkaufen, kann außerdem der European Accessibility Act dafür gelten, wie Sie online verkaufen; unser [Leitfaden zum EAA](/de/blog/european-accessibility-act-online-stores) erklärt seinen Geltungsbereich. Das ist keine Rechtsberatung.

## Wie sollte ein SaaS-Team Barrierefreiheit testen?

1. **Automatisieren Sie die Grundlagen.** Führen Sie axe-core oder eine ähnliche Engine in Ihren End-to-End-Tests und auf der Marketing-Website aus, und lassen Sie Builds bei neuen Verstößen fehlschlagen. Unser [kostenloser Barrierefreiheits-Check](/de/website-accessibility-checker) nutzt dieselbe Engine für jede öffentliche Seite.
2. **Testen Sie mit der Tastatur.** Erledigen Sie Ihre wichtigsten Arbeitsabläufe, etwa die Registrierung, das Anlegen eines Datensatzes und das Ändern von Einstellungen, nur mit Tab, Umschalt+Tab, Enter, Leertaste, Escape und den Pfeiltasten.
3. **Testen Sie mit einem Screenreader.** NVDA unter Windows und VoiceOver unter macOS und iOS sind kostenlos. Prüfen Sie, ob Namen, Rollen, Zustände und Meldungen angesagt werden.
4. **Zoomen und Fenstergröße ändern.** Prüfen Sie 200 % Textzoom und ein 320 Pixel breites Fenster.
5. **Beheben Sie Fehler im Designsystem.** Die meisten Fehler stammen aus gemeinsam genutzten Komponenten; wer einen Button oder Dialog einmal korrigiert, korrigiert ihn überall.

## Häufig gestellte Fragen

### Gilt WCAG auch für die eingeloggten Bereiche einer Web-App?

WCAG gilt für alle Webinhalte, auch für Seiten hinter einem Login. Ob ein Gesetz verlangt, dass ein bestimmtes Produkt die Richtlinien erfüllt, hängt von der Rechtsordnung und vom Kunden ab, aber Käufer, die nach Barrierefreiheit fragen, meinen meist das gesamte Produkt.

### Kann ein Overlay ein SaaS-Produkt barrierefrei machen?

Nein. Overlays ändern nicht den zugrunde liegenden Code eigener Komponenten, und genau dort entstehen die Fehler in Anwendungen. Unser Leitfaden zu [Barrierefreiheits-Overlays](/de/blog/accessibility-overlays-ftc-order) behandelt das Vorgehen der FTC gegen einen führenden Overlay-Anbieter.

### Wie viel von WCAG können automatisierte Tools prüfen?

Nur einen Teil. Automatisierte Regeln finden fehlende Namen, Labels und Kontrastfehler zuverlässig, aber viele Kriterien, etwa eine sinnvolle Fokusreihenfolge, nützliche Alternativtexte und verständliche Fehlermeldungen, muss ein Mensch beurteilen.

### Welche WCAG-Version sollten wir anstreben?

WCAG 2.2 Stufe AA ist die aktuelle Version. Viele Gesetze und Beschaffungsregeln verweisen noch auf WCAG 2.1 AA; wer 2.2 AA erfüllt, erfüllt auch 2.1 AA, abgesehen vom gestrichenen Kriterium Parsing.

### Müssen wir Stufe AAA erfüllen?

Das W3C empfiehlt nicht, AAA für ganze Produkte vorzuschreiben, weil manche Inhalte nicht jedes AAA-Kriterium erfüllen können. Stufe AA ist das übliche Ziel.

## Quellen

- W3C: [What's New in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (Modal) Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)