Roadmap für ein barrierefreies Web: von der WCAG-Checkliste zum Produktsystem

1. Konformitätsziel, Geltungsbereich und Nutzeraufgabe gemeinsam definieren

WCAG 2.2 definiert drei Konformitätsstufen: A, AA und AAA. Für die Stufe AA müssen alle Erfolgskriterien der Stufen A und AA erfüllt sein; bewertet wird jeweils die vollständige Seite, und responsive Ansichten gehören dazu. Das W3C empfiehlt außerdem nicht, die Stufe AAA als allgemeine Richtlinie für ganze Websites verbindlich vorzuschreiben. Klären Sie zuerst mit Fachleuten, welche rechtlichen, vertraglichen und branchenspezifischen Anforderungen für Ihr Unternehmen gelten, und halten Sie danach Ihr technisches Ziel schriftlich fest.W3C — Web Content Accessibility Guidelines (WCAG) 2.2

Ein Standardziel allein ist noch kein Geltungsbereich. Listen Sie Domains, das mobile Web, Bereiche hinter dem Login, Dokument- und Videoformate, Bezahl- oder Terminstrecken von Drittanbietern, unterstützte Sprachen und Altanwendungen auf. Komponenten, über die Sie keine Kontrolle haben, verschwinden nicht als „nicht im Geltungsbereich“, sondern werden über Lieferantenrisiko, alternative Wege und einen Zeitplan für die Behebung gesteuert. Solange ein kurzer Satz wie „neue Hauptwebsite, WCAG 2.2 AA“ ohne diese Grenzen und ohne Ausnahmeprozess bleibt, misst jedes Team ein anderes Projekt.

Verknüpfen Sie den Geltungsbereich mit Nutzeraufgaben wie Konto eröffnen, Produkt finden, bezahlen und Unterstützung erhalten. Eine wenig besuchte Seite zum Zurücksetzen des Passworts kann ein kritischer Zugang sein; über die Priorität entscheiden nicht die Zugriffszahlen allein, sondern wie unverzichtbar die Aufgabe und wie gravierend die Barriere ist.

2. Statt Seiten zu zählen ein Inventar aus Templates, Komponenten und Inhalten erstellen

Tausende URLs einzeln aufzulisten verdeckt die immer gleichen Ursachen. Ordnen Sie die Seiten ihren Grundtemplates zu: Startseite, Übersicht, Detail, Suche, Formular, Konto und Transaktionsansicht. Erfassen Sie anschließend die gemeinsam genutzten Komponenten wie Menü, Modal, Tabs, Auswahllisten, Datentabellen, Benachrichtigungen und Datei-Uploads. Auf der Inhaltsseite machen Sie Überschriftenstruktur, Linktexte, Alternativtexte, Untertitel, Transkripte und den Prozess der PDF-Erstellung getrennt sichtbar.

Die Ausgangsmessung braucht eine ausgewogene Stichprobe. Wählen Sie Seiten mit hohem Traffic, kritischen Aufgaben, unterschiedlicher Technik, altem Bestand und bekannten Beschwerden. Ein automatischer Scan findet fehlende Beschriftungen, einen Teil der Kontrastprobleme und problematische Codemuster schnell. Er kann jedoch nicht allein belegen, ob die Fokusreihenfolge sinnvoll ist, ob eine Fehlermeldung verständlich ist oder ob sich die Aufgabe mit einem Screenreader tatsächlich abschließen lässt.

Die Ressourcen des W3C zur Konformitätsbewertung stellen WCAG-EM als Vorgehen vor, um die Konformität von Websites mit den WCAG zu bestimmen. Das Berichtswerkzeug übernimmt die Prüfung nicht für Sie, sondern unterstützt die Bewertungsschritte und die Berichterstattung. Dieser Unterschied ist wichtig: Die Ausgabe eines Werkzeugs ist Eingangsmaterial für Ihren Nachweis, aber keine Konformitätsentscheidung.W3C WAI — Conformance Evaluation and Reports

3. Befunde nach Schweregrad, Verbreitung und Wiederholungsrisiko ordnen

Jedem Befund nur eine WCAG-Nummer zuzuweisen ergibt noch keine Produktliste. Beschreiben Sie die Auswirkung auf die Nutzung: Ist die Aufgabe vollständig blockiert, erfordert sie erheblichen Mehraufwand oder ist sie nur leicht unbequem? Ergänzen Sie, wie viele Templates und Komponenten betroffen sind, ob es einen Behelfsweg gibt und wie hoch das Risiko ist, dass die Korrektur andere Abläufe stört. Eine Tastaturfalle im gemeinsamen Menü kann Vorrang vor einer kleinen Kontrastabweichung auf einer einzelnen Seite haben.

Die Verantwortung verteilt sich auf mehrere Ebenen. Das Produktmanagement verantwortet Geltungsbereich und Priorität, das Design die barrierefreien Zustände und Interaktionen, die Redaktion Sprache, Struktur und Medienalternativen, die Entwicklung die semantische Umsetzung und die Qualitätssicherung die wiederholbaren Tests. Die Rechtsabteilung legt das Ziel aus, entwirft aber nicht allein eine nutzbare Lösung. Auf jede Arbeitskarte gehören Abnahmekriterium, Testumgebung, verantwortliche Rolle und prüfende Person.

Kennzeichnen Sie die Ursache als Designsystem, Inhaltstemplate, Anwendungscode, Drittanbieter oder redaktionellen Prozess. Beheben Sie die gemeinsame Komponente statt einzelner Fehler und nehmen Sie deren Zustände sowie alle Templates, die sie verwenden, in den Regressionstest auf.

• Für jeden Befund sind betroffene Nutzergruppe und Aufgabe ausdrücklich festgehalten.
• Schweregrad, Verbreitung, Behelfsweg und Wiederholungsrisiko sind bewertet.
• Die umsetzende Rolle und eine unabhängige prüfende Rolle stehen fest.
• Probleme aus gemeinsamen Komponenten sind von einzelnen URLs getrennt.
• Die Abnahmekriterien decken Tastatur, Screenreader und Zoom ab.
• Für Barrieren bei Drittanbietern sind Lieferantenweg und Alternative geplant.

4. Barrierefreiheit in die Qualitätsprüfpunkte von Design und Auslieferung einbauen

In der Designphase müssen für jede Komponente das Tastaturverhalten, die Darstellung des Fokus, Fehler- und Leerzustände, das Verhalten bei vergrößertem Text und der Name für assistive Technologien festgelegt sein. Wird nur der ideale Screenshot übergeben, rät die Entwicklung das unsichtbare Verhalten. Auch das Inhaltsmodell muss Überschriftenebenen, aussagekräftige Linktexte und Medienalternativen in den Arbeitsablauf der Redaktion einbinden.

Im Code bildet semantisches HTML die Grundlage; eigene Interaktionen bauen Sie nur bei echtem Bedarf. Komponententests decken barrierefreien Namen, Rolle, Zustand und Tastaturverhalten ab, Seitentests den Fokusverlauf und die Fehlerbehebung. Automatische Prüfungen liefern schnelles Feedback im Pull Request, manuelle Szenarien und Tests mit assistiven Technologien laufen gegen den Auslieferungskandidaten. Forschung mit Menschen mit Behinderungen zeigt dem Team schließlich jene Entscheidungen, die ein Kriterium technisch erfüllen und die reale Aufgabe trotzdem erschweren.

Kritische Barrieren stoppen die Auslieferung; Befunde mit geringerem Risiko können mit verantwortlicher Rolle und Datum in ein Schuldenregister wandern. Bei einer Ausnahme müssen betroffene Nutzergruppe, alternativer Zugang, Begründung und Ablaufdatum sichtbar sein.

5. Hypothetisches Szenario: die Antragsstrecke neu priorisieren

Dieses Szenario ist hypothetisch und weder ein Kundenergebnis noch ein Leistungsversprechen. Angenommen, eine Serviceplattform hat 400 Inhaltsseiten, 12 gemeinsame Templates und eine vierstufige Antragsstrecke. Der automatische Scan liefert vor allem Alternativtexte bei dekorativen Bildern und Kontrastbefunde mit geringer Wirkung. Der Tastaturtest zeigt dagegen, dass sich die Datumsauswahl nicht wieder verlassen lässt, und der Screenreader-Test, dass die Fehlerzusammenfassung im dritten Schritt nicht vorgelesen wird. Der Antrag ist der Zugang zur Kernleistung der Organisation.

Das Team bewertet seine Eingaben nach Traffic, Kritikalität der Aufgabe, Schwere der Barriere und gemeinsamer Ursache. Die Entscheidung lautet nicht, zuerst Hunderte Bildeinträge abzuarbeiten, sondern Datumsauswahl und Fehlerzusammenfassung zu Aufgaben zu machen, die die Auslieferung blockieren. Das Team für das Designsystem korrigiert die barrierefreie Datumseingabe und das Fehlermuster, während die Redaktion einen Entscheidungsbaum für dekorative und informationstragende Bilder erstellt. Die Anmeldung über einen Drittanbieter kommt zusätzlich in das Lieferantenregister.

Die Prüfung verfolgt statt eines einzelnen Punktwerts zwei reale Aufgaben: den Antrag allein mit der Tastatur absenden sowie einen Fehler mit dem Screenreader finden und korrigieren. Die Korrekturen werden in den unterstützten Kombinationen aus Browser und assistiver Technologie erneut getestet. Die Entscheidungslogik ist eindeutig: zuerst das Problem, das den Zugang zur Leistung blockiert, dann das systemische Problem mit großer Wiederholungsfläche, danach die Inhaltsschuld mit geringem Schweregrad.

6. Der operative Plan für die ersten 90 Tage der Barrierefreiheit

Bestimmen Sie in den ersten 30 Tagen Sponsor, Produktverantwortung und technische Leitung und halten Sie Standardziel, Geltungsbereich und die unterstützten Testkombinationen schriftlich fest. Wählen Sie die kritischen Nutzerreisen aus und erstellen Sie das Inventar aus Templates und Komponenten. Verbinden Sie Nutzerbeschwerden, automatische Scans und manuelle Aufgabentests zu einer Ausgangsübersicht. Das Ergebnis dieser Phase ist keine fehlerfreie Website, sondern ein gemeinsam getragenes Bild der Risiken.

Beheben Sie zwischen Tag 31 und 60 die kritischen Barrieren und die Ursachen in gemeinsamen Komponenten. Ergänzen Sie das Designsystem um barrierefreie Zustände, den Redaktionsleitfaden um Regeln zu Überschriften, Links und Medien sowie die Entwicklungsvorlage um Abnahmekriterien. Geben Sie Lieferanten messbare Anforderungen vor. Prüfen Sie mindestens eine kritische Nutzerreise mit Teilnehmenden mit Behinderungen oder in einer geeigneten Bewertung durch erfahrene Nutzerinnen und Nutzer und verknüpfen Sie die Befunde mit Produktentscheidungen.

Verankern Sie zwischen Tag 61 und 90 die automatischen Tests in der kontinuierlichen Integration und die manuellen Prüfungen in der Freigabeliste. Verfolgen Sie Behebungsdauer, wiederkehrende Fehler und den Erfolg kritischer Aufgaben. Binden Sie einen barrierefreien Rückmeldekanal an die Produktliste an und legen Sie der Leitung das verbleibende Risiko samt Ausnahmefristen vor.

• Tag 0–30: Ziel, Geltungsbereich, Aufgaben und Ausgangsbewertung stehen.
• Tag 31–60: kritische Barrieren und Probleme gemeinsamer Komponenten werden behoben.
• Tag 31–60: die Leitfäden für Design, Inhalt und Code sind aktualisiert.
• Tag 61–90: automatische und manuelle Qualitätsprüfpunkte sind aktiv.
• Tag 61–90: Rückmeldung, Kennzahlen und Ausnahmeverwaltung funktionieren.

7. Grenzen und Fehlermuster: Konformität ist nicht die ganze Nutzbarkeit

Die WCAG liefern eine belastbare und prüfbare gemeinsame Grundlage, decken aber nicht im Alleingang alle Bedürfnisse jeder Behinderungsart, jedes Kontexts und jeder Kombination von Voraussetzungen ab. Technische Konformität bedeutet nicht, dass ein Produkt für alle Menschen einfach ist. Ergänzen Sie den Standardtest deshalb um Aufgabenerfolg, Rückmeldungen aus dem Support, Verständlichkeit der Inhalte und Forschung mit Menschen mit Behinderungen. Dieser Beitrag ist zudem keine rechtliche Konformitätsauskunft; Pflichten aus Land, Branche und Verträgen sind mit Fachleuten zu klären.

Häufige Fehler sind, einen automatischen Punktwert zur Konformität zu erklären, Barrierefreiheit an eine einzelne Fachkraft abzugeben und Drittanbieter auszublenden. Overlay-Werkzeuge ersetzen die Behebung grundlegender Codeprobleme nicht, und eine einmalige Prüfung erkennt keine Regressionen aus späteren Änderungen.

Damit das Programm Bestand hat, wählen Sie wenige, dafür aussagekräftige Kennzahlen. Die Zahl offener Fehler allein ist ein schlechtes Maß; ein besserer Bericht zeigt blockierende Fehler in kritischen Aufgaben, die Testabdeckung gemeinsamer Komponenten, die Behebungsdauer, wiederkehrende Ursachen und Nutzerrückmeldungen gemeinsam. Ziel ist nicht der grüne Bericht, sondern dass eine Zugangsbarriere im laufenden System nur schwer erneut entsteht.