Barrierefreiheit im Web klingt für viele nach einem großen, technischen Regelwerk, das nur Fachleute verstehen. In Wahrheit steckt dahinter ein einfacher Gedanke: Eine Website sollte für möglichst alle Menschen nutzbar sein, unabhängig davon, ob jemand mit der Maus, der Tastatur oder einem Screenreader arbeitet, ob jemand gut sieht oder auf hohe Kontraste angewiesen ist. Weltweit leben rund 1,3 Milliarden (WHO) Menschen mit einer wesentlichen Behinderung, in Deutschland waren zuletzt rund 7,8 Millionen (Statistisches Bundesamt) Menschen als schwerbehindert erfasst. Gleichzeitig zeigt die jährliche Auswertung von einer Million Startseiten, dass 95,9 Prozent (WebAIM Million) automatisch erkennbare Verstöße gegen die Web Content Accessibility Guidelines aufweisen. Die WCAG 2.2 sind der internationale Standard dafür, und die Stufe AA ist die in der Praxis maßgebliche Zielmarke. Dieser Beitrag erklärt die vier Bereiche, die im Alltag den größten Unterschied machen: Kontraste, Tastaturbedienung, Screenreader-Unterstützung und Formulare, jeweils verständlich und mit konkreten Umsetzungstipps.
Was WCAG 2.2 AA eigentlich bedeutet
WCAG steht für Web Content Accessibility Guidelines, eine Sammlung von Erfolgskriterien, die das World Wide Web Consortium herausgibt. Die Version 2.2 ist seit Oktober 2023 die offizielle Empfehlung (W3C) und ergänzt die frühere Fassung um neun zusätzliche Kriterien, ohne die alten aufzuheben. Die Richtlinien sind in drei Konformitätsstufen gegliedert: A als Mindestmaß, AA als praxisrelevanter Standard und AAA als höchste Ausbaustufe, die sich nicht für jeden Inhalt vollständig erreichen lässt. Wenn im Web von barrierefreier Gestaltung die Rede ist, ist fast immer die Stufe AA gemeint, denn auf sie beziehen sich auch der European Accessibility Act und das deutsche Barrierefreiheitsstärkungsgesetz.
Alle Kriterien lassen sich auf vier Grundprinzipien zurückführen, im Englischen mit dem Merkwort POUR zusammengefasst. Inhalte müssen wahrnehmbar sein, damit sie über verschiedene Sinne aufgenommen werden können. Sie müssen bedienbar sein, also auch ohne Maus funktionieren. Sie müssen verständlich sein, in Sprache und Aufbau. Und sie müssen robust sein, damit sie mit unterschiedlichen Geräten und Hilfsmitteln zuverlässig arbeiten. Wer diese vier Ideen im Kopf behält, versteht die meisten Einzelregeln fast von selbst. Warum Barrierefreiheit inzwischen für viele Anbieter auch eine gesetzliche Frage ist, erläutern wir ausführlich im Beitrag zur BFSG-Pflicht für barrierefreie Websites.
Die vier Prinzipien der WCAG
Kontraste: sichtbar für alle
Der häufigste Mangel im Web ist zu geringer Kontrast. In der großen Stichprobe wiesen 81 Prozent (WebAIM Million) aller untersuchten Startseiten Textstellen mit unzureichendem Kontrast auf. Das betrifft nicht nur Menschen mit einer Sehbehinderung, sondern jeden, der eine Seite bei Sonnenlicht auf dem Smartphone liest oder an einem älteren Bildschirm arbeitet. Die WCAG legen dafür klare Mindestwerte fest, die sich mit einfachen Werkzeugen messen lassen. Der Kontrast wird als Verhältnis zwischen Vordergrund- und Hintergrundhelligkeit angegeben, von 1:1 bei gleicher Farbe bis 21:1 bei reinem Schwarz auf Weiß.
| Element | Mindestkontrast (AA) |
|---|---|
| Normaler Text | 4,5:1 |
| Großer Text (ab 24px oder 18,66px fett) | 3:1 |
| Bedienelemente und aktive UI-Teile | 3:1 |
| Wesentliche Grafiken und Symbole | 3:1 |
| Sichtbarer Fokusrahmen | 3:1 zum Umfeld |
Wichtig ist außerdem, dass Farbe niemals der einzige Träger einer Information sein darf. Ein Pflichtfeld allein rot einzufärben genügt nicht, weil Menschen mit einer Farbsehschwäche den Unterschied nicht erkennen. Besser ist eine Kombination aus Farbe, einem Symbol und einem Text wie einem Sternchen oder dem Hinweis Pflichtfeld. Auch Links im Fließtext sollten sich nicht nur durch die Farbe vom umgebenden Text abheben, sondern zusätzlich durch eine Unterstreichung. Wer einen Dunkelmodus anbietet, sollte die Kontraste dort ebenso prüfen, denn helle Schrift auf dunklem Grund folgt denselben Regeln.
Praxis-Tipp für Kontraste
Tastaturbedienung: ohne Maus ans Ziel
Viele Menschen bedienen eine Website ausschließlich mit der Tastatur, etwa weil eine motorische Einschränkung die Maus erschwert oder weil ein Screenreader zum Einsatz kommt. Das zentrale Kriterium lautet deshalb: Alles, was mit der Maus geht, muss auch mit der Tastatur gehen. In der Praxis heißt das, dass sich jedes Bedienelement mit der Tabulatortaste erreichen und mit Enter oder Leertaste auslösen lässt, dass die Reihenfolge dabei logisch dem sichtbaren Aufbau folgt und dass man mit der Tastatur nie in einer Komponente hängen bleibt, aus der man nicht mehr herausnavigieren kann.
Genauso wichtig ist ein sichtbarer Fokus. Wer sich mit der Tabulatortaste durch eine Seite bewegt, muss jederzeit erkennen, wo er gerade steht. Ein deutlich sichtbarer Rahmen oder eine Hervorhebung um das aktive Element ist deshalb Pflicht, und die WCAG 2.2 haben die Anforderungen an diese Fokusdarstellung noch geschärft. Der verbreitete Fehler, den Fokusrahmen aus gestalterischen Gründen per CSS zu entfernen, macht eine Seite für Tastaturnutzer praktisch unbrauchbar. Ein Skip-Link, der als erstes fokussierbares Element direkt zum Hauptinhalt springt, spart zusätzlich den Weg durch die gesamte Navigation.
- Jedes Bedienelement ist mit der Tabulatortaste erreichbar
- Die Fokusreihenfolge folgt der sichtbaren Anordnung
- Der Fokus ist immer deutlich sichtbar hervorgehoben
- Menüs, Dialoge und Slider lassen sich per Tastatur bedienen
- Aus keiner Komponente entsteht eine Tastaturfalle
- Ein Skip-Link führt direkt zum Hauptinhalt
Neu in WCAG 2.2: größere Klickflächen
Screenreader: semantisches HTML als Fundament
Ein Screenreader liest eine Website vor und macht sie so für blinde und stark sehbeeinträchtigte Menschen nutzbar. Damit das gelingt, muss der Aufbau einer Seite nicht nur optisch, sondern auch im Quelltext stimmen. Das wichtigste Werkzeug dafür ist semantisches HTML, also die Verwendung der richtigen Elemente für ihre eigentliche Bedeutung. Eine Überschrift gehört in ein Überschriften-Element, ein Button in ein Button-Element, eine Navigation in einen Navigationsbereich. Ein per CSS wie ein Button aussehendes Nicht-Button-Element mag optisch überzeugen, für den Screenreader bleibt es unsichtbar oder unverständlich.
Besonders wichtig ist eine saubere Überschriften-Hierarchie. Es sollte genau eine Hauptüberschrift geben, darunter folgen Unterüberschriften in logischer Verschachtelung, ohne Ebenen zu überspringen. Viele Screenreader-Nutzer springen gezielt von Überschrift zu Überschrift, um sich einen Überblick zu verschaffen, ähnlich wie sehende Menschen eine Seite überfliegen. Ebenso zentral sind aussagekräftige Alternativtexte für Bilder, die den Inhalt oder die Funktion eines Bildes beschreiben, sowie Bereichsauszeichnungen für Kopf, Navigation, Hauptinhalt und Fuß, damit die Struktur der Seite ansteuerbar wird.
Semantische Elemente
Überschriften, Buttons, Listen und Links im richtigen Element. So kennt der Screenreader Rolle und Bedeutung jedes Bausteins, ohne raten zu müssen.
Alt-Texte
Jedes inhaltstragende Bild bekommt einen kurzen, beschreibenden Alternativtext. Rein dekorative Bilder werden leer ausgezeichnet und übersprungen.
Landmarks
Kopf, Navigation, Hauptinhalt und Fuß als eigene Bereiche. Nutzer springen direkt zum relevanten Abschnitt, statt alles der Reihe nach zu hören.
Wo natives HTML nicht ausreicht, etwa bei aufwendigen interaktiven Komponenten, kommen ARIA-Attribute ins Spiel. Sie ergänzen fehlende Rollen, Zustände und Beschriftungen für Hilfsmittel. Der wichtigste Grundsatz dabei lautet: so wenig ARIA wie möglich. Ein falsch gesetztes Attribut richtet oft mehr Schaden an als gar keines, weil es dem Screenreader eine falsche Bedeutung vorgaukelt. Semantisches HTML zuerst, ARIA nur dort, wo es wirklich nötig ist, sorgfältig getestet mit einem echten Screenreader. Wie technische Sauberkeit und Nutzerfreundlichkeit zusammenspielen, zeigt auch unser Beitrag zum Mobile-First-Design.
Formulare: klar führen, Fehler benennen
Formulare sind die Stellen, an denen Barrieren besonders teuer werden, denn hier findet die eigentliche Handlung statt: eine Anfrage, eine Anmeldung, eine Bestellung. Fehlt einem Eingabefeld die zugeordnete Beschriftung, weiß ein Screenreader-Nutzer nicht, was einzutragen ist, und auch bei automatisch ausgefüllten Feldern entsteht Verwirrung. Jedes Feld braucht deshalb ein sichtbar und technisch verknüpftes Label. Ein Platzhaltertext im Feld ist kein Ersatz, weil er beim Tippen verschwindet und oft zu geringen Kontrast hat.
Der zweite kritische Punkt sind Fehlermeldungen. Wenn eine Eingabe nicht akzeptiert wird, muss klar werden, welches Feld betroffen ist und was zu tun ist, in verständlicher Sprache und nicht allein über eine Farbe. Die Meldung sollte dem betroffenen Feld eindeutig zugeordnet und für den Screenreader hörbar gemacht werden, damit sie nicht unbemerkt bleibt. Pflichtfelder werden eindeutig gekennzeichnet, und passende autocomplete-Angaben erlauben es dem Browser, bekannte Daten wie Name oder E-Mail-Adresse anzubieten, was allen Nutzern Zeit spart. Weil gut bedienbare Formulare zugleich die Zahl abgeschlossener Anfragen erhöhen, lohnt sich der Aufwand doppelt, wie unser Beitrag zur Conversion-Optimierung zeigt.
- Jedes Eingabefeld hat ein sichtbares, verknüpftes Label
- Pflichtfelder sind nicht allein über Farbe gekennzeichnet
- Fehlermeldungen benennen Feld und Lösung in klarer Sprache
- Fehler werden dem Feld zugeordnet und dem Screenreader angesagt
- Passende autocomplete-Attribute erleichtern das Ausfüllen
- Der Fokus springt bei einem Fehler nachvollziehbar an die richtige Stelle
Von der Prüfung zur Umsetzung
Barrierefreiheit ist kein Häkchen, das man einmal setzt, sondern ein fortlaufender Prozess, der am besten von Beginn an mitgedacht wird. Am Anfang steht eine ehrliche Bestandsaufnahme. Automatische Prüfwerkzeuge finden schnell einen Teil der Probleme, etwa fehlende Alt-Texte oder schwache Kontraste. Sie erfassen aber nur einen Bruchteil der Kriterien, oft wird der Anteil auf rund ein Drittel geschätzt. Der Rest lässt sich nur durch manuelle Prüfung erkennen: einmal die ganze Seite nur mit der Tastatur bedienen, einmal mit einem Screenreader durchgehen, die Struktur der Überschriften kontrollieren. Erst die Kombination aus automatischem Test und menschlicher Prüfung ergibt ein belastbares Bild.
Aus dieser Bestandsaufnahme entsteht eine Prioritätenliste. Sinnvoll ist, zuerst die Barrieren zu beheben, die viele Nutzer betreffen und leicht zu ändern sind, etwa Kontraste und Formular-Labels, und danach die aufwendigeren Punkte wie komplexe interaktive Komponenten anzugehen. Wichtig ist eine realistische Erwartung: Vollständige Konformität mit jedem einzelnen Kriterium ist ein anspruchsvolles Ziel, und einzelne Detailfragen bleiben immer Interpretationssache. Entscheidend ist die konsequente Ausrichtung an den WCAG 2.2 auf Stufe AA und die Bereitschaft, gemeldete Probleme zeitnah zu beheben. Wie wir Barrierefreiheit in unsere Arbeit einbinden, beschreibt unsere Seite zu barrierefreien Websites, und die technischen Grundlagen sauberer Gestaltung finden Sie auf unserer Seite zum Webdesign.
Barrierefreiheit nützt allen