Website barrierefrei machen: ein WCAG-2.2-Einstieg

Um eine Website barrierefrei zu machen, baust du sie so, dass Menschen sie mit der Tastatur, einem Screenreader, Zoom oder einem Schaltergerät nutzen können, nicht nur mit der Maus. Verwende echte HTML-Elemente für Buttons, Links, Überschriften und Formularbeschriftungen, gib Bildern aussagekräftige Alt-Texte, halte den Textkontrast hoch und mach den Fokus sichtbar. Ziel ist WCAG 2.2 Stufe AA. Automatische Prüfer finden einen Teil des Problems; ein zehnminütiger Test mit Tastatur und Screenreader findet einen großen Rest.

Was „barrierefrei“ in der Praxis bedeutet

Barrierefreiheit betrifft Menschen: jemanden, der blind ist und einen Screenreader nutzt, jemanden mit Tremor, der mit der Tastatur navigiert, jemanden mit eingeschränktem Sehvermögen, der auf 200 % zoomt, jemanden, der im grellen Sonnenlicht liest, oder jemanden mit einem vorübergehend gebrochenen Handgelenk. Gute Barrierefreiheit macht eine Seite meist für alle besser: klarere Struktur, lesbare Texte, Formulare, die ihre Fehler erklären.

Der Referenzstandard sind die Web Content Accessibility Guidelines (WCAG) des W3C. Stand September 2026 ist die aktuelle Version WCAG 2.2 (veröffentlicht im Oktober 2023, aktualisiert im Dezember 2024); WCAG 3 ist ein früher Entwurf. WCAG ist um vier Prinzipien herum aufgebaut: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein, und es gibt drei Konformitätsstufen:

Stufe	Was sie bedeutet	Wer sie anstrebt
A	Das Minimum; ohne sie können manche Menschen die Seite gar nicht nutzen	Alle
AA	Das übliche Ziel; umfasst Kontrast, Fokus, Skalierbarkeit und Fehlerbehandlung	Die meisten Organisationen und viele Gesetze
AAA	Die strengste Stufe; nicht für alle Inhalte erreichbar	Bestimmte Dienste und Zielgruppen

Gesetze an mehreren Orten verweisen auf WCAG, zum Beispiel der European Accessibility Act, der seit Juni 2025 für viele digitale Verbraucherdienste in der EU gilt. Welche Regeln für dich gelten, hängt davon ab, wo du tätig bist und was du verkaufst; bei Unsicherheit frag einen Berater. Dieser Leitfaden behandelt die praktische Arbeit.

Optionen: so kommst du hin

Ansatz	Gut für	Abwägung
Von Anfang an einbauen	Neue Websites und Apps	Insgesamt der geringste Aufwand; muss von Beginn an vorgegeben werden
Prüfen und beheben	Bestehende Websites	Findet echte Probleme; braucht einen fokussierten Durchgang pro Seite
Professionelle Prüfung	Regulierte Branchen, große Websites, öffentliche Stellen	Gründlich und dokumentiert; kostet Geld
Overlay-Widget	Nicht empfohlen	Kann den darunterliegenden Code nicht reparieren

Für die meisten kleinen Websites reichen die ersten beiden Ansätze: Sag der KI, dass sie von Anfang an barrierefrei bauen soll, und prüfe vor dem Start.

Die Korrekturen, die am meisten zählen

Die richtigen HTML-Elemente verwenden

Die meiste Barrierefreiheit gibt es mit korrektem HTML umsonst. Ein <button> ist fokussierbar, reagiert auf Enter und Leertaste und wird als Button angekündigt. Ein <div> mit einem Klick-Handler kann all das nicht. KI-generierter Code verwendet manchmal gestylte divs für alles; verlange semantische Elemente:

<button> für Aktionen, <a href> für Navigation
Eine <h1> pro Seite, dann <h2>, <h3> in der richtigen Reihenfolge; Screenreader-Nutzer springen zwischen Überschriften
Landmarks: <header>, <nav>, <main>, <footer>
Ein <label>, das mit jedem Formularfeld verbunden ist
Die Sprache der Seite in <html lang="de">

Verwende ARIA-Attribute nur, wenn kein natives Element passt, etwa bei einer eigenen Tab-Gruppe oder Combobox. Falsches ARIA ist schlechter als gar keins.

Tastaturbedienung und sichtbarer Fokus

Alles, was du mit der Maus tun kannst, muss auch allein mit der Tastatur funktionieren (WCAG 2.1.1). Drück Tab durch die Seite: Jeder Link, Button und jedes Feld sollte in logischer Reihenfolge erreichbar sein, und du solltest immer sehen, wo der Fokus liegt (2.4.7 Fokus sichtbar). WCAG 2.2 ergänzt, dass das fokussierte Element nicht vollständig von fixierten Kopfzeilen oder Cookie-Bannern verdeckt werden darf (2.4.11, Stufe AA).

Typische Fehler: Menüs, die nur beim Hovern aufgehen, Dialoge, die den Fokus nicht festhalten oder sich nicht mit Escape schließen lassen, und outline: none im CSS ohne Ersatz.

Textalternativen

Jedes inhaltlich wichtige Bild braucht einen Alt-Text, der im Kontext sagt, was es zeigt („Koch beim Anrichten des Degustationsmenüs“, nicht „bild1.jpg“). Dekorative Bilder erhalten ein leeres alt="", damit Screenreader sie überspringen. Icon-Buttons brauchen einen zugänglichen Namen („Schließen“, „Suche“). Videos brauchen Untertitel, Audio ein Transkript.

Farbe und Kontrast

WCAG 2.2 AA verlangt ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text (1.4.3) sowie 3:1 für Bedienelemente wie Eingabefeld-Rahmen und aussagekräftige Icons (1.4.11). Hellgrauer Platzhaltertext und blasse Buttons sind die üblichen Fehler. Außerdem sollte Farbe nie allein Bedeutung tragen: Ein roter Rahmen bei einem ungültigen Feld braucht zusätzlich eine Fehlermeldung.

Skalierung und Umbruch

Der Text muss bei 200 % Zoom nutzbar bleiben (1.4.4), und Inhalte müssen bei 320 CSS-Pixeln Breite ohne seitliches Scrollen funktionieren (1.4.10). Ein sauber responsives Layout erledigt das meiste davon.

Zielgrößen, Formulare und Fehler

Zielgröße: WCAG 2.2 AA verlangt für Zeigeziele mindestens 24 × 24 CSS-Pixel oder ausreichenden Abstand um kleinere (2.5.8). Größer ist auf Smartphones freundlicher.
Formulare: sichtbare Beschriftungen (nicht nur Platzhalter), klare Hinweise und Fehlermeldungen, die sagen, was falsch ist und wie man es behebt, direkt am Feld.
Login: Verlange kein Rätsel und keine abzutippende Zahlenfolge ohne Alternative; erlaube Passwort-Manager und Einfügen (3.3.8 Barrierefreie Authentifizierung).

Prompts, die funktionieren

Baue diese Website so, dass sie WCAG 2.2 Stufe AA erfüllt: semantische HTML-Landmarks, eine h1 pro Seite mit Überschriften in der richtigen Reihenfolge, echte Button- und Link-Elemente, Beschriftungen für jedes Formularfeld, sichtbare Fokus-Stile, Textkontrast von mindestens 4,5:1, Alt-Texte für inhaltlich wichtige Bilder und alt="" für dekorative, und ein gesetztes html lang.

Prüfe die Seiten /signup und /checkout auf Barrierefreiheit. Kontrolliere die Bedienung nur mit der Tastatur, die Fokus-Reihenfolge, den sichtbaren Fokus, Beschriftungen, Fehlermeldungen, Kontrast und die Screenreader-Namen von Icon-Buttons. Liste jedes Problem mit dem WCAG-Kriterium auf und behebe sie dann, ohne das visuelle Design mehr als nötig zu verändern.

Das mobile Menü lässt sich nicht mit der Tastatur bedienen. Mach daraus einen Button mit aria-expanded, verschiebe den Fokus beim Öffnen in das Menü, schließe es mit Escape und gib den Fokus an den Button zurück.

Schritt für Schritt

Führe eine automatische Prüfung aus. Den Bereich Barrierefreiheit in Lighthouse in den Chrome-Entwicklerwerkzeugen oder die Browser-Erweiterung axe, auf jeder wichtigen Seite. Behebe alles, was sie meldet.
Nimm die Maus weg. Geh mit Tab durch jede Seite und erledige jede wichtige Aufgabe: sich anmelden, suchen, bezahlen. Notiere alles, was du nicht erreichst, wo du den Fokus nicht siehst oder wo du nicht herauskommst.
Zoome auf 200 % und verkleinere das Fenster auf Smartphone-Breite. Nichts darf abgeschnitten sein oder seitliches Scrollen erfordern.
Probiere einen Screenreader zehn Minuten lang aus: VoiceOver auf Mac und iPhone, TalkBack auf Android oder NVDA unter Windows (kostenlos). Hör dir Überschriften, Links und Formularfelder an. „Button“ ohne Namen oder „Link, hier klicken“ bedeutet Arbeit.
Prüfe den Kontrast von Text, Buttons und Eingabefeldern mit einem Kontrastprüfer.
Behebe, dann prüfe erneut dieselben Aufgaben.
Veröffentliche eine Barrierefreiheitserklärung, die sagt, welchen Standard du anstrebst und wie man Probleme meldet, und beantworte diese Meldungen.

Häufige Fehler

Sich auf ein Overlay-Widget verlassen, statt den Code zu reparieren.
Fokus-Rahmen entfernen, weil sie unordentlich aussehen, ohne Ersatz.
Platzhaltertext als einzige Beschriftung. Er verschwindet, sobald jemand tippt, und ist oft kontrastarm.
„Hier klicken“- und „Weiterlesen“-Links. Ohne Kontext hören Screenreader-Nutzer eine Liste identischer Links.
Alt-Texte voller Keywords. Alt-Texte sind für Menschen; beschreibe das Bild.
Nur einmal testen. Jede neue Funktion kann die Tastaturbedienung brechen. Nimm einen Tastatur-Durchgang in deine Tests vor dem Start auf.

Checkliste zur Barrierefreiheit

Automatische Prüfung (Lighthouse oder axe) auf den wichtigen Seiten ohne Befund
Jede Aufgabe ist allein mit der Tastatur erledigbar
Fokus ist immer sichtbar und nie hinter fixierten Elementen verborgen
Semantische Überschriften, Landmarks, Buttons und Links; lang gesetzt
Aussagekräftige Alt-Texte; dekorative Bilder alt=""; Untertitel bei Videos
Textkontrast ≥ 4,5:1 (großer Text ≥ 3:1); Bedienelemente ≥ 3:1
Funktioniert bei 200 % Zoom und 320 px Breite
Jedes Formularfeld hat eine sichtbare Beschriftung und klare Fehlermeldungen
Barrierefreiheitserklärung mit einer Möglichkeit, Probleme zu melden

Zu den Konzepten dahinter lies was Web-Barrierefreiheit ist. Barrierefreies und gutes Design überschneiden sich stark; wie du mit KI eine gut aussehende App gestaltest behandelt die visuelle Seite.

Barrierefreiheit auf Mythex

Mythex baut nach dem Standard, den du verlangst. Schreib deshalb „WCAG 2.2 AA“ in deinen ersten Prompt und in jede Folgeanfrage. Mit dem Vorschau-Rahmen in Smartphone-Größe kannst du kleine Bildschirme prüfen (Vorschau und Code), aber Tests mit Tastatur, Zoom und Screenreader funktionieren am besten auf der veröffentlichten URL oder einer Vorschau in einem eigenen Tab. Bitte den Agenten, eine Seite zu prüfen, die Befunde zu beheben, und teste die Korrekturen dann selbst. Ein automatischer Durchgang ist ein Anfang, keine Freigabe.

Fragen

Was ist der aktuelle Barrierefreiheits-Standard für Websites?

Stand September 2026 ist der aktuelle W3C-Standard WCAG 2.2, erstmals veröffentlicht im Oktober 2023. Die meisten Organisationen und viele Gesetze zielen auf Stufe AA. WCAG 3 ist noch ein früher Entwurf.

Kann ein Barrierefreiheits-Overlay meine Website konform machen?

Verlass dich nicht darauf. Overlays legen eine Werkzeugleiste über die Seite, können aber fehlende Beschriftungen, kaputte Tastaturbedienung oder schlechte Struktur im darunterliegenden Code nicht beheben. Die Website selbst zu reparieren ist das, was sie tatsächlich nutzbar macht.

Finden automatische Prüfer jedes Problem?

Nein. Werkzeuge wie Lighthouse und axe erkennen Dinge wie fehlende Alt-Texte, geringen Kontrast und unbeschriftete Felder. Viele Probleme, etwa eine verwirrende Fokus-Reihenfolge, nichtssagende Linktexte oder Alt-Texte, die zwar vorhanden, aber falsch sind, muss ein Mensch mit Tastatur und Screenreader prüfen.

Welches Kontrastverhältnis verlangt WCAG?

WCAG 2.2 Stufe AA verlangt mindestens 4,5:1 für normalen Text und 3:1 für großen Text sowie 3:1 für Bedienelemente der Oberfläche wie Eingabefeld-Rahmen und Icons, die eine Bedeutung vermitteln.