Website nach WCAG 2.2 gezielt barriereärmer machen

Diese Anleitung führt dich durch einen modularen WCAG-2.2-Workflow: erst relevante Nutzerpfade, dann wiederverwendbare Bausteine, anschließend Umsetzung, Prüfung und Dokumentation.

Wichtige Seiten und Aufgaben auswählen
Zentrale Komponenten priorisieren
Navigation, Fokus und Seitenstruktur verbessern
Formulare, Bedienelemente und Medien bearbeiten
Änderungen manuell und automatisiert prüfen

Warum du nicht auf den nächsten Relaunch warten musst

Barrierefreiheit wird häufig als Eigenschaft einer vollständig neu entwickelten Website behandelt. Das führt bei bestehenden Websites schnell zu einer unpraktischen Entscheidung: kompletter Relaunch oder vorerst gar nichts. Für viele kleine Websites und Agenturprojekte ist ein modularer Ansatz sinnvoller.

Dabei verbesserst du zuerst Komponenten, die auf vielen Seiten vorkommen oder für zentrale Aufgaben benötigt werden. Eine korrigierte Hauptnavigation hilft beispielsweise auf der gesamten Website. Ein verständlicher Formularbaustein verbessert jedes Formular, das ihn verwendet. Der Effekt wiederverwendbarer Komponenten ist deshalb meist größer als die isolierte Überarbeitung einer beliebigen Unterseite.

WCAG steht für „Web Content Accessibility Guidelines“. Die Richtlinien beschreiben überprüfbare Anforderungen an barrierefreie Webinhalte. WCAG 2.2 ist seit dem 5. Oktober 2023 eine W3C-Empfehlung und ergänzt WCAG 2.1 um neun Erfolgskriterien. Für die praktische Arbeit bedeutet das nicht, dass du neun Punkte an eine alte Checkliste hängst. Du brauchst einen Ablauf, der Anforderungen in konkrete Komponenten, Tests und redaktionelle Regeln übersetzt.

Lege zuerst die wichtigen Nutzerpfade fest

Beginne nicht automatisch mit der Startseite. Entscheidend ist, welche Aufgaben ein Besucher auf deiner Website erledigen soll. Ein Nutzerpfad ist die Folge von Seiten und Interaktionen, die zu einem bestimmten Ziel führt.

Für eine kleine Unternehmenswebsite könnten das beispielsweise diese Pfade sein:

Leistung finden, Details lesen und Kontakt aufnehmen
Öffnungszeiten oder Kontaktdaten finden
Beitrag aufrufen und ein verlinktes Dokument herunterladen
Formular ausfüllen, Fehler korrigieren und Bestätigung erhalten
Konto öffnen, anmelden und eine wichtige Einstellung ändern

Wähle zunächst wenige Pfade aus, die fachlich wichtig sind oder besonders viele Interaktionen enthalten. Ein Kontaktformular eignet sich besser als Einstieg als eine selten besuchte Impressumsseite, weil dort Navigation, Beschriftungen, Tastaturbedienung, Validierung und Rückmeldung zusammenspielen.

Notiere für jeden ausgewählten Pfad:

Start- und Zielseite
beteiligte Seitentypen und Komponenten
notwendige Aktionen
mögliche Fehlerzustände
eine kurze Beschreibung des erfolgreichen Abschlusses

Damit hast du einen prüfbaren Umfang. „Die Website barrierefrei machen“ ist kein brauchbares Arbeitspaket. „Kontaktanfrage vollständig per Tastatur absenden und fehlerhafte Felder verständlich korrigieren“ dagegen schon.

Priorisiere wiederverwendbare Bausteine

Erstelle anschließend ein kleines Komponenten-Inventar. Dafür brauchst du kein vollständiges Designsystem. Eine Liste der wiederkehrenden Bedienelemente und Inhaltsmuster reicht zunächst aus.

Typische Kandidaten sind:

Hauptnavigation und mobile Navigation
Buttons, Textlinks und verlinkte Karten
Formularfelder, Auswahlfelder und Fehlermeldungen
Akkordeons, Tabs, Dialogfenster und Menüs
Hinweise, Erfolgsmeldungen und Warnungen
Bilder, Videos und eingebettete Inhalte
Seitentitel, Überschriften und Inhaltsbereiche

Bewerte jeden Baustein nach zwei Fragen: Auf wie vielen relevanten Seiten kommt er vor, und wie stark blockiert ein Fehler die Nutzung? Eine nicht bedienbare mobile Navigation hat eine hohe Reichweite und kann den gesamten weiteren Pfad verhindern. Ein unpassender Alternativtext in einem dekorativen Bild ist ebenfalls zu korrigieren, blockiert aber meist keine zentrale Aufgabe.

Bearbeite zuerst Bausteine mit hoher Reichweite und hoher Auswirkung. Danach folgen Komponenten, die nur in einzelnen Nutzerpfaden vorkommen. So entsteht eine nachvollziehbare Reihenfolge statt einer Sammlung zufällig entdeckter Einzelprobleme.

Die Seitenstruktur sollte im HTML erkennbar sein und nicht nur durch Schriftgröße oder Abstände entstehen. Nutze echte Überschriften für Abschnitte und halte ihre Hierarchie nachvollziehbar. Eine kleinere Schrift ist noch keine Unterüberschrift, auch wenn sie sich sehr überzeugend dafür hält.

Prüfe auf jedem priorisierten Seitentyp:

Gibt es einen eindeutigen Seitentitel und eine verständliche Hauptüberschrift?
Beschreiben Zwischenüberschriften den folgenden Inhalt?
Lassen sich Navigation und Hauptinhalt semantisch unterscheiden?
Gibt es einen Sprunglink, mit dem Tastaturnutzer wiederkehrende Navigation überspringen können?
Bleibt die Reihenfolge beim Durchlaufen mit der Tabulatortaste logisch?

Die sichtbare Fokusmarkierung zeigt, welches Bedienelement gerade per Tastatur ausgewählt ist. Entferne sie nicht aus gestalterischen Gründen. Definiere lieber einen einheitlichen Fokusstil für Links, Buttons und Formularfelder. Er sollte sich deutlich vom normalen Zustand unterscheiden und auch auf wechselnden Hintergründen erkennbar bleiben.

Prüfe außerdem, ob der Fokus durch feststehende Kopfzeilen, Cookie-Hinweise oder andere überlagernde Elemente verdeckt wird. Zu den zusätzlichen Kriterien von WCAG 2.2 gehören unter anderem sichtbarer Fokus, Mindestgrößen für Bedienelemente, konsistente Hilfe und barriereärmere Authentifizierung. Diese Anforderungen betreffen damit sehr alltägliche Komponenten und keineswegs nur Spezialfälle.

Mobile Menüs brauchen einen echten Bedienzustand

Ein Schalter für die mobile Navigation sollte technisch ein Button sein. Sein zugänglicher Name muss die Funktion beschreiben, und der geöffnete beziehungsweise geschlossene Zustand sollte für Hilfstechnologien erkennbar sein. Dafür werden häufig ARIA-Attribute verwendet. ARIA ergänzt semantische Informationen, wenn natives HTML allein den Zustand nicht ausdrückt.

Beim Öffnen und Schließen darf der Tastaturfokus nicht verschwinden. Teste außerdem, ob das Menü mit der Escape-Taste geschlossen werden kann, wenn dies dem gewählten Interaktionsmuster entspricht. Unsichtbare Menüpunkte dürfen nicht weiterhin mit der Tabulatortaste erreichbar sein.

Mach Links, Buttons und Formulare verständlich bedienbar

Links führen zu einem anderen Ziel, Buttons lösen eine Aktion aus. Diese Unterscheidung sollte auch im HTML gelten. Ein optisch wie ein Button gestalteter Link ist in Ordnung, wenn er tatsächlich eine andere Seite öffnet. Ein Link, der ohne Zieladresse ein Formular absendet oder einen Dialog öffnet, erschwert dagegen Tastaturbedienung und Zustandsvermittlung.

Beschrifte Bedienelemente so, dass ihre Funktion im jeweiligen Kontext verständlich ist. Wiederholte Linktexte wie „Mehr“ oder „Hier klicken“ sind besonders unpraktisch, wenn mehrere davon in einer Liste auftauchen. Sichtbare, konkrete Bezeichnungen wie „Leistungsdetails Webentwicklung“ sind meist verständlicher als eine nachträglich ergänzte, nur technisch verfügbare Beschriftung.

Bei Symbol-Buttons muss der Zweck ebenfalls zugänglich sein. Ein Lupensymbol braucht beispielsweise eine Bezeichnung wie „Suche öffnen“. Der Dateiname des Symbols ist keine Bezeichnung und „icon-12-final.svg“ war vermutlich ohnehin nie als redaktionelle Meisterleistung gedacht.

Formulare brauchen mehr als Platzhalter

Jedes Formularfeld benötigt eine dauerhaft erkennbare Beschriftung. Ein Platzhalter ersetzt diese Beschriftung nicht, weil er beim Tippen verschwindet und häufig nur schwach dargestellt wird. Hinweise zum erwarteten Format gehören in einen erklärenden Text, der dem Feld technisch zugeordnet ist.

Prüfe Formulare in dieser Reihenfolge:

Kannst du alle Felder und Bedienelemente mit der Tastatur erreichen?
Ist jedes Feld eindeutig beschriftet?
Werden Pflichtfelder verständlich gekennzeichnet?
Sind zusammengehörige Optionen als Gruppe erkennbar?
Bleiben eingegebene Werte nach einem Validierungsfehler erhalten?
Wird der Fehler am betroffenen Feld konkret beschrieben?
Erfährt der Nutzer, ob das Formular erfolgreich übermittelt wurde?

Eine Fehlermeldung wie „Ungültige Eingabe“ hilft kaum. „Gib deine E-Mail-Adresse im Format name@beispiel.de ein“ erklärt, was korrigiert werden muss. Verlasse dich außerdem nicht allein auf eine rote Umrandung. Farbe kann den Zustand unterstützen, sollte aber nicht die einzige Information transportieren.

Bei längeren Formularen ist eine Fehlerübersicht am Anfang sinnvoll. Ihre Einträge sollten zu den betroffenen Feldern führen. Setze den Fokus nach dem Absenden so, dass die Rückmeldung erreichbar und verständlich ist. Ob er auf die Übersicht, die Meldung oder das erste fehlerhafte Feld gehört, hängt vom Aufbau des Formulars ab; entscheidend ist ein konsistenter, getesteter Ablauf.

Prüfe Bilder, Medien und Authentifizierung im Kontext

Ein Alternativtext beschreibt nicht pauschal, was auf einem Bild zu sehen ist. Er vermittelt die Information oder Funktion, die das Bild im aktuellen Zusammenhang erfüllt. Ein dekoratives Bild benötigt deshalb in der Regel einen leeren Alternativtext, damit es von Screenreadern übersprungen werden kann. Ein Diagramm braucht dagegen eine textliche Vermittlung seiner relevanten Aussage.

Bei verlinkten Bildern beschreibt der zugängliche Name das Linkziel oder die Aktion. Wiederhole nicht zusätzlich sichtbare Bildunterschriften, wenn dadurch nur identische Informationen mehrfach vorgelesen werden.

Für Videos und Audiodateien hängt die passende Alternative vom Inhalt ab. Gesprochene Inhalte benötigen eine Textalternative; bei Videos können Untertitel und gegebenenfalls Beschreibungen wichtiger visueller Informationen erforderlich sein. Prüfe auch eingebettete Player: Sie müssen per Tastatur bedienbar sein, verständlich beschriftete Steuerelemente besitzen und dürfen den Fokus nicht festhalten.

Wenn dein priorisierter Nutzerpfad eine Anmeldung enthält, kontrolliere unnötige kognitive Hürden. Verhindere beispielsweise nicht ohne zwingenden Grund das Einfügen eines Passworts aus einem Passwortmanager. Authentifizierung ist kein Eignungstest für das Kurzzeitgedächtnis.

Teste die Änderungen in mehreren kurzen Durchläufen

Automatisierte Prüfwerkzeuge finden bestimmte technische Probleme, etwa fehlende Beschriftungen, ungültige Strukturen oder einige Kontrastfehler. Sie können aber nicht zuverlässig beurteilen, ob ein Alternativtext den Zweck eines Bildes erfüllt, eine Fokusreihenfolge fachlich sinnvoll ist oder eine Fehlermeldung verständlich formuliert wurde. Ein grüner Scanner-Haken ist daher ein Hinweis, kein Konformitätsnachweis.

Nutze für jede überarbeitete Komponente denselben kompakten Testablauf:

Tastaturtest: Bediene den vollständigen Nutzerpfad mit Tabulator, Umschalt-Tabulator, Eingabetaste, Leertaste und bei passenden Komponenten Escape sowie Pfeiltasten.
Sichtprüfung: Kontrolliere Fokuszustände, Textvergrößerung, Überlagerungen, Kontraste und die Darstellung bei engem Browserfenster.
Browserwerkzeuge: Prüfe im Accessibility-Baum, also der für Hilfstechnologien aufbereiteten Seitenstruktur, Namen, Rollen und Zustände interaktiver Elemente.
Automatisierter Scan: Suche nach maschinell erkennbaren Fehlern und ordne jeden Fund der betroffenen Komponente zu.
Gezielter Screenreader-Test: Prüfe wichtige Navigationen, Formulare, Dialoge und Rückmeldungen mit einem Screenreader, sofern die nötige Bedienkompetenz vorhanden ist.

Teste nicht nur den idealen Ablauf. Sende ein leeres Formular ab, gib ein ungültiges Format ein, öffne und schließe ein Menü mehrfach und verlasse einen Dialog ohne Abschluss. Viele Barrieren stecken in Zuständen, die in einer statischen Seitenansicht nicht vorkommen.

Dieser Ablauf ersetzt keine vollständige WCAG-Prüfung. Er ist dafür geeignet, klar begrenzte Verbesserungen belastbar umzusetzen und offensichtliche Fehler früh zu finden. Eine spezialisierte Analyse ist sinnvoll, wenn du eine formale Konformitätsaussage brauchst, komplexe individuelle Komponenten betreibst, besonders kritische Dienste anbietest oder intern nicht ausreichend testen kannst.

Mach aus den Ergebnissen einen wiederholbaren Workflow

Barrierefreiheit bleibt nur dann erhalten, wenn die Erkenntnisse in Entwicklung und Contentpflege einfließen. Das W3C empfiehlt, Barrierefreiheit in den gesamten Entwicklungsprozess einzubetten, mit schnellen Verbesserungen zu beginnen und Fortschritte zu dokumentieren.

Lege deshalb für jede Änderung ein kleines, einheitliches Arbeitspaket an. Es sollte folgende Angaben enthalten:

betroffener Nutzerpfad und betroffene Komponente
konkrete Barriere und ihre Auswirkung
angestrebtes WCAG-Level oder relevantes Erfolgskriterium
geplante technische oder redaktionelle Änderung
manuelle Abnahmeschritte
Testergebnis und bekannte Einschränkungen

Übernimm gelöste Probleme anschließend in deine Komponenten- und Redaktionsregeln. Wenn ein Formularfeld korrigiert wurde, sollte die Lösung im zentralen Formularbaustein landen und nicht nur auf einer einzelnen Seite. Wenn Alternativtexte regelmäßig fehlen, braucht der Redaktionsprozess eine verständliche Eingabehilfe und eine Prüfung vor der Veröffentlichung.

Ergänze außerdem Barrierefreiheitskriterien in die Definition of Done, also die Bedingungen, die eine Aufgabe vor ihrer Abnahme erfüllen muss. Für eine neue interaktive Komponente könnten das Tastaturbedienung, sichtbarer Fokus, verständliche Beschriftung, getestete Fehlerzustände und ein dokumentiertes Prüfergebnis sein.

Wähle ein realistisches Ziel für Level A oder AA

Die WCAG ordnet Erfolgskriterien den Stufen A, AA und AAA zu. Für die Konformität mit einem Level müssen auch die Anforderungen der darunterliegenden Level erfüllt sein. Einzelne korrigierte Komponenten machen daher noch keine vollständige Website konform.

Level A kann als dokumentiertes Zwischenziel dienen, wenn du eine bestehende Website schrittweise sanierst und den Umfang klar benennst. Es sollte nicht als bequeme Schlusslinie verwendet werden, falls wesentliche Barrieren aus Level AA bestehen bleiben.

Level AA ist häufig das sinnvollere technische Projektziel, wenn du eine breite Zugänglichkeit systematisch anstrebst oder entsprechende vertragliche beziehungsweise rechtliche Anforderungen erfüllen musst. Ob und welche gesetzlichen Vorgaben für deine Website gelten, hängt jedoch vom konkreten Angebot, Betreiber und Anwendungsfall ab. Kläre diese Frage getrennt vom technischen Verbesserungsplan und hole bei Bedarf fachkundige rechtliche Beratung ein.

Solange du nur einzelne Nutzerpfade oder Komponenten geprüft hast, ist „barriereärmer“ die präzisere Bezeichnung. Eine Aussage zur WCAG-Konformität verlangt einen festgelegten Umfang und eine vollständige Prüfung aller darin relevanten Anforderungen.

Ein sinnvoller erster Durchlauf

Für eine kleine Website kannst du mit einem einzigen wichtigen Pfad beginnen: Navigation öffnen, Leistungsseite aufrufen, Kontaktformular ausfüllen und Bestätigung erhalten. Dabei bearbeitest du nacheinander die globale Navigation, Überschriftenstruktur, Links und Buttons, Formularfelder, Validierung sowie Rückmeldungen.

Nach der Umsetzung führst du den Pfad vollständig per Tastatur aus, prüfst Namen und Zustände in den Browserwerkzeugen, lässt einen automatisierten Scan laufen und kontrollierst die kritischen Stellen gezielt mit einem Screenreader. Die Ergebnisse dokumentierst du an den betroffenen Komponenten und übernimmst allgemeine Regeln in die künftige Entwicklung und Contentpflege.

So wird eine große, schwer greifbare Aufgabe zu einer Folge überprüfbarer Verbesserungen. Der entscheidende Fortschritt entsteht nicht durch möglichst viele einzelne Korrekturen, sondern durch Bausteine, die danach auf allen relevanten Seiten korrekt verwendet und bei weiteren Änderungen erneut getestet werden.

Kann ich eine bestehende Website ohne Relaunch barriereärmer machen?

Ja. Beginne mit wichtigen Nutzerpfaden und wiederverwendbaren Komponenten wie Navigation, Buttons und Formularfeldern. Ein Relaunch wird erst nötig, wenn grundlegende technische oder gestalterische Strukturen sinnvolle Verbesserungen verhindern.

Reicht ein automatisierter Accessibility-Test aus?

Nein. Automatisierte Werkzeuge finden nur bestimmte technische Fehler. Tastaturbedienung, sinnvolle Fokusreihenfolgen, verständliche Fehlermeldungen und passende Alternativtexte musst du zusätzlich manuell beurteilen.

Sollte ich für meine Website WCAG Level A oder AA anstreben?

Level A kann bei einer schrittweisen Überarbeitung ein klar bezeichnetes Zwischenziel sein. Für eine systematische Verbesserung ist Level AA häufig das sinnvollere technische Ziel. Rechtliche oder vertragliche Anforderungen musst du für deinen konkreten Anwendungsfall gesondert klären.

Wann brauche ich eine professionelle WCAG-Prüfung?

Eine spezialisierte Prüfung ist sinnvoll, wenn du eine formale Konformitätsaussage benötigst, komplexe eigene Komponenten verwendest, kritische Dienste anbietest oder intern keine ausreichende Erfahrung mit manuellen Accessibility-Tests vorhanden ist.

Website Schritt für Schritt nach WCAG 2.2 barriereärmer machen