WCAG-Richtlinien im Behörden- und Konzernumfeld

© AnnaStills

WCAG-Richtlinien im Überblick

Digitale Barrierefreiheit wird in Behörden und Konzernen oft dann akut, wenn Fachverfahren ausgerollt werden, Portale zusammenwachsen oder Abnahmen anstehen. In solchen Phasen treffen drei Probleme aufeinander:

• Viele beteiligte Teams
• Gewachsene Oberflächen
• Wenig Zeit für Nachbesserungen

Genau dafür liefern die WCAG-Richtlinien einen gemeinsamen Maßstab – unabhängig davon, ob es um Websites, Web Apps oder allgemein um barrierefreie Software (z. B. Verwaltungssoftware mit webbasiertem Frontend) geht.
Aktuelle Daten zeigen, warum das relevant ist: Laut HTTP Archive Web Almanac 2025 erfüllen nur 31 % der mobilen Websites die Mindestanforderungen an Textkontrast. Gleichzeitig entfernen 67 % der Websites explizit die Standard-Fokus-Markierung – ein Risiko für Tastaturnutzung. Und nur rund 35 % der mobilen Eingabefelder erhalten ihren zugänglichen Namen über ein korrektes Label.

Was sind die vier Prinzipien der WCAG-Richtlinien?

Die WCAG unterteilen Anforderungen in vier Prinzipien: wahrnehmbar, bedienbar, verständlich und robust. Diese Einteilung ist weniger Theorie als Sortierhilfe für reale Probleme: Kontrast, Beschriftungen und Alternativtexte landen bei „wahrnehmbar“, während Fokusführung, Tastaturbedienbarkeit und Interaktionsmuster bei „bedienbar“ liegen. „Verständlich“ greift bei Formularlogik, Fehlerhinweisen oder Authentifizierungsabläufen, „robust“ bei der technischen Verlässlichkeit für Assistenztechnologien.

Im Behörden- und Konzernumfeld steckt der Nutzen darin, Anforderungen in Prozesse zu übersetzen: Ein Portal kann optisch modern sein und dennoch in Sachen Bedienbarkeit scheitern – etwa in mehrstufigen Anträgen, SSO-Logins oder komplexen Tabellenmasken. Das betrifft nicht nur das Web, sondern auch barrierefreie Softwareanwendungen, sofern sie über Webtechnologien bereitgestellt werden oder Webinhalte integrieren.

WCAG-Richtlinien und Erfolgskriterien

WCAG steht für „Web Content Accessibility Guidelines“. Herausgegeben werden sie vom W3C (World Wide Web Consortium), einer internationalen Standardisierungsorganisation für das Web. Weiteres Hintergrundwissen zur Umsetzung der digitalen Barrierefreiheit in Deutschland liefert unser Leitfaden zum Barrierefreiheitsstärkungsgesetz.

Spezifikation der WCAG-Kriterien

Für die Umsetzung sind die Erfolgskriterien entscheidend, weil sie messbar definieren, was erfüllt sein muss. Die einzelnen Spezifikationen sind in Abschnitte unterteilt, denen jeweils spezifische Nummernfolgen zugeordnet sind. Diese setzen sich wie folgt zusammen:

• erste Zahl = Prinzip
• zweite Zahl = Richtlinie
• dritte Zahl = konkretes Erfolgskriterium

Wichtig für die Praxis: WCAG 2.2 hat neue Kriterien bewusst ans Ende bestehender Richtlinien angehängt, um die Nummerierung aus vorhergehenden Versionen stabil zu halten – dadurch bleibt z. B. „2.5.8“ über Versionen hinweg eindeutig referenzierbar.

Was ist neu an WCAG 2.2 im Vergleich zu WCAG 2.1 – und welche Änderungen betreffen AA direkt?

WCAG 2.2 erweitert WCAG 2.1. Relevant sind vor allem Kriterien, die typische Hürden moderner Oberflächen adressieren: Fokus wird verdeckt, Ziele sind zu klein, Drag-&-Drop ist alternativlos, Logins und Formulare erzeugen unnötige Reibung.

WCAG 2.2: Überblick der neuen A/AA-Kriterien

Für WCAG AA sind vor allem sechs neue A/AA-Erfolgskriterien relevant:

• 2.4.11 ☛ Fokus nicht verdeckt (Minimum) (AA)
• 2.5.8 ☛ Zielgröße (Minimum) (AA)
• 2.5.7 ☛ Ziehende Bewegungen / Dragging Movements (AA)
• 3.3.8 ☛ Barrierefreie Authentifizierung (Minimum) (AA)
• 3.3.7 ☛ Redundante Eingabe (A)
• 3.2.6 ☛ Konsistente Hilfe (A)

Diese Anforderungen lassen sich als Standards in Komponenten, Prozessstrecken und Content-Regeln verankern.

Fokus und Sichtbarkeit in Interfaces (2.4.11)

„Fokus“ ist die sichtbare Markierung dafür, welches Element gerade per Tastatur aktiv ist. WCAG 2.2 nimmt ein häufiges Problem ins Visier: Banner, Sticky-Elemente oder Widgets verdecken den Fokusbereich. 2.4.11 fordert, dass ein fokussiertes Element nicht vollständig durch andere Inhalte verdeckt wird. Konkret bedeutet das:

• Banner und Overlays so einsetzen, dass Fokus und Fokusmarkierung sichtbar bleiben
• Dialoge so gestalten, dass der Fokus im Dialog bleibt und nicht „hinter“ dem Overlay
• Tastatur-Durchlauf als Standardcheck für Kernprozesse (Start → Formular → Abschluss)

Das reduziert Abnahme-Risiken, weil Tastaturprobleme ganze Prozessketten blockieren können – unabhängig davon, ob Screenreader im Spiel sind oder nicht.

Bedienelemente und Zielgröße (2.5.8)

2.5.8 „Zielgröße (Minimum)“ betrifft die Trefferfläche von Bedienelementen. Gerade in Verwaltungs- und Konzernsoftware entstehen Barrieren durch kleine Icon-Buttons, dichte Tabellenaktionen oder eng gesetzte Filter. WCAG 2.2 nennt 24×24 als Mindestzielgröße – alternativ muss Abstand oder eine gleichwertige Bedienmöglichkeit vorhanden sein. Die Zielgröße ist ein Fehlbedienungsschutz: Größere, sauber getrennte Aktionen senken Fehlklicks, Abbrüche und Supportaufwände – und sie stabilisieren die Nutzung bei eingeschränkter Feinmotorik.

WCAG-Konformitätsstufen und Nachweise

Wichtig in Bezug auf barrierefreie Softwareanwendungen ist: EN 301 549 beschreibt Anforderungen für IKT-Produkte und -Dienste und ist für webbasierte, nicht-webbasierte und hybride Technologien gedacht. Für nicht-webbasierte Software gibt es zusätzlich W3C-Leitlinien (WCAG2ICT), welche die WCAG 2.2 Level A/AA auf Dokumente und Software übertragen helfen. Aber was genau sind diese A-Level in der digitalen Barrierefreiheit?

WCAG-Konformitätsstufen: A, AA, AAA

Die WCAG-Konformitätsstufen sind eine Art „Qualitätsstufe“, mit der sich Barrierefreiheit eindeutig beschreiben lässt. Stufe A bildet das Mindestniveau. Stufe AA (oft als WCAG AA bezeichnet) bedeutet: Alle Anforderungen aus A und AA sind erfüllt – nicht nur „die wichtigsten“. Stufe AAA ist die höchste Stufe und umfasst zusätzlich alle AAA-Anforderungen.

Für Roadmaps ist AA häufig der sinnvollste Zielpunkt: Es deckt die typischen Nutzungshürden ab, die in Portalen, Fachverfahren und Web Apps im Alltag am stärksten wirken (Bedienbarkeit, Orientierung, Formstrecken) – ohne den Anspruch, jedes Spezialkriterium von AAA flächendeckend zu erfüllen. Genau deshalb weist die WCAG selbst darauf hin, dass AAA nicht als pauschale Vorgabe für komplette Websites empfohlen wird.

Konformität ist dabei kein „Etikett für einzelne Screens“. Sie gilt immer für ganze Seiten und – für die Praxis entscheidend – für komplette Abläufe: Wenn ein Antrag oder Prozess aus mehreren Schritten besteht, wird die Barrierefreiheit in der Realität meist genau dort eingeschränkt, wo ein Schritt scheitert. Deshalb lohnt ein Standard-Ansatz: zentrale UI-Bausteine und Prozessmuster (Fokusführung, Zielgröße, stabile Formulare) werden so festgelegt, dass sie in jeder neuen Funktion wiederverwendbar sind.

Umsetzung von WCAG 2.2

Damit WCAG 2.2 nicht als übergroßer Katalog wirkt, hilft eine klare Priorisierung entlang realer Risiken: Fokus/Orientierung, robuste Bedienbarkeit (Zielgröße) und stabile Prozessstrecken (Login/Formulare). Genau diese Themen lösen in Behörden und Konzernen die meisten Reibungen aus – und sie sind vergleichsweise gut standardisierbar.

Automatisierte Checks können wertvolle Ressourcen sparen. Entscheidend bleibt jedoch ein kurzer, manueller Prozesscheck der wichtigsten Journeys, weil Fokus- und Ablaufprobleme häufig erst dort auffallen.

Authentifizierung und Formulare (3.3.8, 3.3.7)

In Fachverfahren und Self-Service-Portalen sind Login und Formulare die kritischen Bereiche. WCAG 2.2 ergänzt Anforderungen, die direkt auf Durchlaufquoten und Support wirken: 3.3.8 fordert Authentifizierung ohne unnötige kognitive Hürden (z. B. Abschreiben oder Merken), wenn sichere Alternativen möglich sind. 3.3.7 fordert, redundante Eingaben zu vermeiden, wenn Informationen im Prozess bereits vorliegen.

Im Detail bedeutet das:

• Den Login so gestalten, dass Assistenz, Passwortmanager und Copy-&-Paste nicht unnötig blockiert werden
• Mehrstufige Formulare mit Datenübernahme statt Doppelabfragen
• Verhalten in Fehlerfällen so gestalten, dass Korrekturen ohne Sucharbeit möglich sind (klarer Hinweis, Rücksprung, Fokus)

Drag & Drop und Alternativen (2.5.7)

2.5.7 betrifft Oberflächen, in denen Elemente per Ziehen sortiert oder verschoben werden. WCAG 2.2 verlangt eine Alternative ohne Ziehbewegung. In der Praxis reichen oft zusätzliche Steuerungen („hoch/runter“, „Position ändern“) oder Menüs für bessere Zugänglichkeit, wenn Drag-Gesten unzuverlässig sind.

Mehr zu den WCAG Best Practices und wie wir diese umsetzen ist auf unserer Info-Seite Digitale Barrierefreiheit zu finden.

Weiterführende Informationen

• Barrierefreiheitsgesetz: Grundlagen und Umsetzung – Überblick zu BFSG und gesetzlichen Anforderungen
• Barrierefreie Software für die öffentliche Verwaltung – Umsetzung im Behördenumfeld
• Business Software barrierefrei gestalten – Barrierefreiheit in Unternehmensanwendungen
• App-Entwicklung – Mobile und Web-Apps mit barrierefreiem Design
• IT Service Management – Strukturierte Prozesse für die laufende Qualitätssicherung