WCAG 2.1 AA in Klartext: Die 9 Sachen, die wirklich klicken müssen

WCAG 2.1 hat 78 Erfolgskriterien — 30 in Level A, 20 in Level AA, 28 in Level AAA. Wer das in ein Lehrbuch packt, hat sechs Stunden Lektüre vor sich. Wer das auf einer echten Mittelstands-Website umsetzen will, braucht kein Lehrbuch. Er braucht neun Sachen, die wirklich klicken müssen — den Rest decken die ersten neun ohnehin mit ab.

Wir haben das in über sechzig Audits in den vergangenen zwölf Monaten verdichtet. Hier kommt die Klartext-Liste, gestapelt nach Häufigkeit der Lücken, und mit der konkreten Reparatur-Anweisung pro Punkt.

1. Kontrast: 4,5:1 für normalen Text, 3:1 für große Schrift

Der häufigste Verstoß. Hellgraue Schrift auf weiß ist „edel“, aber für mindestens 12 % der über-Fünfzigjährigen unlesbar. Was zählt:

• Normaler Text (unter 24 px): Kontrast mindestens 4,5:1
• Große Schrift (ab 24 px, oder ab 18 px wenn fett): Kontrast mindestens 3:1
• Bedien-Elemente (Buttons, Links, Form-Fields): Kontrast der visuellen Begrenzung mindestens 3:1

Messen: WebAIM Contrast Checker (kostenlos im Web). Farben deines Textes und Hintergrunds eingeben, Ampel-Anzeige. Lighthouse im Chrome-Browser (DevTools → Lighthouse) findet die Lücken in einem Rutsch über die ganze Seite.

Reparieren: Meist eine CSS-Änderung am Farb-Wert. Wer ein Design-System hat, ändert eine Variable, und es ist überall durch. Wer hartkodierte Farben hat, geht durch die Templates.

2. Tastatur-Navigation: alles erreichbar mit Tab

Jedes Bedien-Element muss mit der Tab-Taste erreichbar sein. Das heißt: keine reinen Mouse-only-Trigger, keine onclick-DIVs ohne Tabindex, keine versteckten Modals, die mit der Tastatur nicht öffenbar sind.

Testen: Auf deine Startseite gehen, die Tab-Taste drücken, durchspringen. Kannst du jedes Bedien-Element erreichen — Logo-Link, Menü-Items, Sub-Menü, Call-to-Action, Form-Fields, Footer-Links? Wenn nein, notieren wo es hakt.

Reparieren: Native HTML-Elemente nutzen (<button>, <a>, <input>) statt klick-DIVs. Wo das nicht geht, tabindex="0" setzen UND die Tastatur-Events ergänzen (Enter + Space).

3. Alt-Texte: jedes Inhalts-Bild beschriftet

Inhaltsrelevante Bilder bekommen einen aussagekräftigen Alt-Text. Pure Deko-Bilder bekommen alt="" (leer, aber vorhanden). Wenn das Attribut ganz fehlt, lesen Screenreader die Dateinummer vor („IMG_4521.jpg“).

Faustregel für Alt-Texte: Beschreib, was auf dem Bild zu sehen ist, in einem ganzen Satz. Beispiel: „Eine Bäckerin zieht ein Blech Brötchen aus dem Ofen, im Hintergrund die Backstube.“ Das ist genau richtig — Kontext genug, ohne Bandwurm.

Reparieren: Bild für Bild durchs CMS gehen. Bei großen Bestands-Mengen: nicht alle gleichzeitig fixen, sondern Top-20 aktive Seiten zuerst, Archiv-Seiten nach und nach. Eine Erklärung zur Barrierefreiheit, die das offen sagt, schützt dich in der Übergangs-Phase.

4. Sichtbare Formular-Labels: Beschriftung, die bleibt

Modernes „cleanes“ Design: ein Eingabefeld mit Platzhalter-Text drin, kein <label>. Sobald der Nutzer reinklickt, ist die Beschriftung weg. WCAG verlangt sichtbare, persistente Labels — am besten oberhalb des Feldes, dauerhaft sichtbar.

Reparieren: Jedes Form-Field bekommt ein echtes <label for="feldid">Beschriftung</label>. Das Label bleibt sichtbar, der Placeholder kann (in Maßen) als Hilfe-Text bleiben — er ist aber kein Label-Ersatz.

5. Fokus-Sichtbarkeit: zeig, wo du gerade bist

Wer mit der Tab-Taste navigiert, muss sehen können, wo der Fokus gerade liegt. Viele Designs entfernen den Standard-Fokus-Rahmen (outline: none in der CSS) aus „Ästhetik-Gründen“ und ersetzen ihn durch nichts.

Reparieren: Entweder den Default-Fokus-Rahmen behalten, oder einen eigenen, deutlich sichtbaren Fokus-Stil definieren — z.B. :focus-visible { outline: 2px solid #1a2740; outline-offset: 2px; }. Wichtig: nicht entfernen ohne Ersatz.

6. ARIA korrekt — nicht „dekorativ“ angeklebt

ARIA (Accessible Rich Internet Applications) sind Attribute, die zusätzlich beschreiben, was ein Element ist und tut. Eingesetzt für interaktive Custom-Komponenten (Akkordeons, Tabs, Modal-Dialoge, Auto-Complete-Suchen).

Häufiger Fehler: ARIA wird „prophylaktisch“ auf normale HTML-Elemente angeklebt („sicherheitshalber“), was den Screenreader verwirrt. Native HTML schlägt ARIA — wer ein <button> nutzt, braucht kein role="button".

Wo ARIA Pflicht ist:

• aria-label für icon-only Buttons (Mülleimer-Symbol ohne Text: aria-label="Element löschen"),
• aria-expanded für Akkordeon-Toggle (gibt offen/zu an),
• aria-current für die aktuelle Seite in der Navigation,
• aria-describedby für Form-Fehler-Meldungen.

7. Skip-Link: zum Hauptinhalt springen

Pflicht-Element. Ganz oben auf der Seite ein „Zum Hauptinhalt springen“-Link, der per Tab als erstes erreichbar wird. Damit Screenreader-Nutzer nicht jedes Mal das gesamte Hauptmenü vorlesen lassen müssen, bevor sie zum eigentlichen Inhalt kommen.

Reparieren: Ein einzelner Link am Anfang des <body>, der per CSS unsichtbar ist, bis er den Fokus bekommt — dann taucht er sichtbar auf. Eine Stunde Arbeit, fertig.

8. Sprachliche Klarheit: Sprache im HTML deklariert

Pflicht-Element: <html lang="de">. Bei mehrsprachigen Seiten zusätzlich pro Abschnitt lang="en" dort, wo der Text englisch wird. Damit Screenreader die richtige Aussprache wählen.

Inhaltlich: Klare Sprache, kein Juristen-Deutsch ohne Übersetzung, Fehlermeldungen mit konkretem Hinweis, was zu tun ist. WCAG AAA verlangt zusätzlich „leichte Sprache“ — für AA reicht klare Standard-Sprache.

9. Responsiver Zoom bis 200 %

Wer schlecht sieht, zoomt im Browser auf 150 % oder 200 %. Deine Seite muss dann immer noch bedienbar bleiben — kein abgeschnittener Text, keine sich überlappenden Elemente, keine horizontal-scrollende Verzweiflung.

Testen: Im Browser STRG-Plus drücken, bis 200 % erreicht ist. Kannst du alles lesen? Sind alle Bedien-Elemente erreichbar?

Reparieren: Responsive Design konsequent durchziehen (mobile first hilft), keine Fixed-Width-Layouts, Schriftgrößen in rem statt px. Wer ein neueres Theme nutzt, ist meist von Haus aus zoom-fest.

Die schnelle Selbst-Prüfung

Wer in einer Stunde wissen will, wie es um die eigene Site steht, läuft folgende Checkliste durch:

1. Lighthouse-Audit im Chrome (DevTools → Lighthouse → Accessibility) — gibt Score 0–100 und Konkret-Liste,
2. Tab-Test durch die Startseite — wo verliert der Fokus die Sichtbarkeit?
3. WebAIM Contrast Checker für drei deiner Hauptfarben gegen den Hintergrund,
4. Browser auf 200 % zoomen und Hauptseite durchschauen,
5. Alt-Text-Stichprobe: letzte 10 Bilder im CMS — wie viele haben sinnvolle Beschriftung?

Wer dabei Lücken findet, weiß, wo zu reparieren ist. Wer keine findet, ist mit hoher Wahrscheinlichkeit schon konform — und kann das in einer kurzen Erklärung zur Barrierefreiheit veröffentlichen.

Was Hannes daraus macht

Jede unserer neuen Sites kommt mit allen neun Punkten standardmäßig konform: passende Kontraste, Skip-Link, Tab-Reihenfolge, Alt-Text-Pflichtfeld im Redaktions-CMS, sichtbarer Fokus-Stil, Form-Labels, responsive bis 200 %, deutsche HTML-Sprache, ARIA wo nötig. Für Bestand-Sites bauen wir nach Audit nach — Festpreis, 1–3 Werktage für die fünf häufigsten Lücken.

Wer prüfen will, wo die eigene Site steht: frag Hannes, er schaut kostenlos drüber. Wer den vollständigen Sanierungs-Weg sehen will: BFSG-Sanierung einer bestehenden Site.