WCAG 2.2 Checkliste: Die wichtigsten Kriterien für barrierefreie Websites

Was sind die WCAG?

WCAG steht für "Web Content Accessibility Guidelines". Das sind die offiziellen Richtlinien des W3C (World Wide Web Consortium) für barrierefreie Websites. Das W3C ist die Organisation, die auch HTML und CSS standardisiert. Die WCAG sind also kein nationales Gesetz, sondern ein internationaler technischer Standard.

Warum sind sie trotzdem gesetzlich relevant? Das Barrierefreiheitsstärkungsgesetz (BFSG) verweist direkt auf WCAG 2.1 Level AA als technischen Mindeststandard. Das bedeutet: Wer das BFSG erfüllen muss, muss die WCAG-AA-Kriterien erfüllen.

WCAG 2.2 vs. 2.1: Was hat sich geändert?

WCAG 2.2 wurde im Oktober 2023 veröffentlicht. Sie enthält 9 neue Erfolgskriterien gegenüber WCAG 2.1. Für die meisten KMU-Websites sind die wichtigsten Neuerungen:

Neu in WCAG 2.2 (Auswahl der relevantesten für Websites):

• 2.4.11 Focus Appearance (AA): Der Tastaturfokus muss eine Mindestgröße und einen Mindestkontrast haben. Das schlechte "outline: none" als CSS-Reset ist jetzt explizit ein Verstoß.
• 2.5.3 Label in Name (A): Der sichtbare Text eines Buttons muss im zugänglichen Namen (Aria-Label) enthalten sein. Wichtig für Sprachsteuerung.
• 3.2.6 Consistent Help (A): Hilfefunktionen (Kontakt, FAQ, Chatbot) müssen an konsistenter Position erscheinen.
• 3.3.7 Redundant Entry (A): Nutzer müssen keine Informationen mehrfach eingeben, die schon abgefragt wurden.
• 3.3.8 Accessible Authentication (AA): Anmelde-Prozesse dürfen keine Gedächtnis- oder Kognitionstests verlangen (z. B. Zeichen abtippen aus einem Bild ohne Alternative).

Das BFSG verweist aktuell auf WCAG 2.1 AA. WCAG 2.2 ist aber der Stand der Technik, und eine Orientierung daran schützt besser vor zukünftigen Anforderungen.

Die 4 POUR-Prinzipien

Alle WCAG-Kriterien basieren auf vier Grundprinzipien, die sich das Akronym POUR merken lassen.

P: Perceivable (Wahrnehmbar)

Alle Inhalte und Informationen müssen so präsentiert werden, dass Nutzer sie wahrnehmen können, auch wenn sie ein bestimmtes Sinnesorgan nicht nutzen können (kein Sehen, kein Hören).

O: Operable (Bedienbar)

Alle Funktionen der Website müssen bedienbar sein, auch ohne Maus, auch mit Sprachsteuerung, auch mit Assistenztechnologien.

U: Understandable (Verständlich)

Inhalte und Bedienung müssen verständlich sein. Das betrifft Sprache, Konsistenz der Navigation und verständliche Fehlermeldungen.

R: Robust

Die Website muss mit aktuellen und zukünftigen Technologien kompatibel sein, insbesondere mit Screenreadern und anderen Hilfsmitteln.

Die WCAG-Level: A, AA und AAA

WCAG-Kriterien sind in drei Konformitätsniveaus eingeteilt:

Für die gesetzliche Konformität nach BFSG reicht Level AA. Level AAA ist für öffentliche Stellen mit besonderen Anforderungen relevant (z. B. Behörden-Websites mit Notfallinformationen).

Die WCAG-Checkliste: Wichtigste AA-Kriterien

Diese Checkliste deckt die Anforderungen ab, die für eine typische KMU-Website am relevantesten sind. Für jede Anforderung gibt es eine kurze Erklärung, ein Beispiel und den häufigsten Fehler.

1. Alternativtexte für Bilder (1.1.1 A)

Jedes informative Bild braucht einen Alt-Text, der den Inhalt des Bildes beschreibt. Dekorative Bilder (Hintergrundbilder, rein visuelle Trenner) bekommen ein leeres Alt-Attribut (alt="").

Gut: alt="Tischler Christian Müller bei der Arbeit in seiner Werkstatt in München"

Schlecht: alt="Bild1" oder alt="image" oder gar kein Alt-Attribut

Häufiger Fehler: Dateinamen als Alt-Text (alt="DSC_0047.jpg"). Das hilft niemandem.

Warum wichtig: Screenreader lesen Alt-Texte vor. Ohne Alt-Text hören blinde Nutzer nur "Grafik" oder den Dateinamen.

2. Kontrastverhältnis Text (1.4.3 AA)

Normaler Text muss ein Kontrastverhältnis von mindestens 4,5:1 zwischen Schrift und Hintergrund haben. Großer Text (18pt oder 14pt fett) braucht mindestens 3:1.

Prüfen: WebAIM Contrast Checker (webaim.org/resources/contrastchecker/) oder das Barrierefreiheit-Check Tool.

Häufiger Fehler: Grauer Text auf weißem Hintergrund (#999 auf #fff = 2,85:1, nicht ausreichend). Oder weiße Schrift auf hellblauem Hintergrund.

Tipp: Bei der Designentscheidung immer zuerst den Kontrast prüfen, bevor Farben festgelegt werden. Nachträglich ändern kostet mehr Zeit.

3. Kontrastverhältnis UI-Elemente (1.4.11 AA)

Nicht nur Text, sondern auch UI-Komponenten (Buttons, Formularfelder, Icons) brauchen ein Kontrastverhältnis von mindestens 3:1 gegenüber dem Hintergrund.

Häufiger Fehler: Hellgraue Checkbox-Rahmen auf weißem Hintergrund. Der Nutzer sieht nicht, wo das Formularfeld ist.

4. Keine ausschließliche Farb-Information (1.4.1 A)

Informationen dürfen nicht ausschließlich über Farbe vermittelt werden. Wenn Pflichtfelder nur durch rote Farbe markiert sind, wissen farbenblinde Nutzer nicht, welche Felder Pflicht sind.

Gut: Pflichtfelder mit roter Farbe UND einem Sternchen (*) und dem Text "Pflichtfeld" markieren.

Häufiger Fehler: Grafiken, in denen Kategorien nur durch Farbe unterschieden werden (z. B. ein Tortendiagramm ohne Beschriftungen).

5. Tastaturnavigation (2.1.1 A)

Alle Funktionen der Website müssen ausschließlich mit der Tastatur bedienbar sein. Das bedeutet: Tab-Taste für Navigation, Enter/Leertaste für Aktivierung, Pfeil-Tasten für Menüs.

Testen: Schließe die Maus an und navigiere deine Website nur mit der Tastatur. Erreichst du alles? Siehst du, wo der Fokus ist?

Häufiger Fehler: Dropdown-Menüs, die sich nur per Hover öffnen. Per Tastatur nicht erreichbar.

6. Sichtbarer Fokus-Indikator (2.4.7 AA, 2.4.11 AA in WCAG 2.2)

Wenn ein Element per Tastatur fokussiert wird, muss das sichtbar sein. Das ist der blaue oder orangene Rahmen, den du beim Tab-Drücken siehst.

Häufiger Fehler: *:focus { outline: none; } im CSS. Das entfernt den Fokusrahmen komplett und macht die Website für Tastatur-Nutzer unbrauchbar.

Gut: Fokus-Indikator anpassen (andere Farbe, andere Form), aber nie komplett entfernen. Bei WCAG 2.2 muss der Fokus-Indikator mindestens 2 CSS-Pixel breit sein und einen Kontrast von 3:1 haben.

7. Überschriften-Hierarchie (1.3.1 A)

Überschriften müssen semantisch korrekt und hierarchisch eingesetzt werden. H1 ist die Hauptüberschrift (einmal pro Seite), H2 sind Abschnittsüberschriften, H3 sind Unterabschnitte.

Häufiger Fehler: H3 nach H1 ohne H2 dazwischen. Oder Überschriften nur für optische Gestaltung nutzen (<h2> für fetten Text, der kein Abschnittstitel ist).

Warum wichtig: Screenreader lesen Überschriften vor und ermöglichen die Navigation per Überschriften-Sprung. Für viele blinde Nutzer ist das die Haupt-Navigationsmethode auf langen Seiten.

8. Aussagekräftige Linktexte (2.4.4 A)

Linktext muss ohne den Kontext um ihn herum verständlich sein. "Hier klicken" oder "Mehr lesen" sind nicht ausreichend, weil Screenreader-Nutzer oft eine Liste aller Links auf der Seite aufrufen.

Gut: "WCAG 2.2 Checkliste herunterladen" oder "Mehr über Barrierefreiheits-Anforderungen"

Schlecht: "Hier klicken", "Weiterlesen", "Mehr"

Häufiger Fehler: "Hier" als Linktext in einem Satz wie "Die Checkliste findest du hier."

9. Sprache der Seite (3.1.1 A)

Das lang-Attribut im <html>-Tag muss die Sprache der Seite angeben. Bei einer deutschen Website: <html lang="de">.

Warum wichtig: Screenreader nutzen das Attribut, um die richtige Aussprache zu wählen. Eine deutsche Seite ohne lang="de" wird vom Screenreader oft auf Englisch vorgelesen.

Häufiger Fehler: Kein lang-Attribut oder das falsche. Besonders häufig: lang="en" auf deutschen Websites (aus einem englischsprachigen Template kopiert).

10. Formular-Labels (1.3.1 A, 3.3.2 A)

Jedes Formularfeld braucht ein sichtbares Label, das dem Feld programmatisch zugeordnet ist.

Gut: <label for="email">E-Mail-Adresse</label><input type="email" id="email">

Schlecht: Nur Placeholder-Text (placeholder="E-Mail-Adresse"). Placeholder verschwindet beim Tippen. Screenreader lesen Placeholder oft nicht korrekt vor.

Häufiger Fehler: Labels visuell neben dem Feld platzieren, aber nicht programmatisch verknüpfen (for- und id-Attribut fehlen).

11. Fehlermeldungen beschreiben das Problem (3.3.1 A, 3.3.3 AA)

Wenn ein Formular einen Fehler enthält, muss die Fehlermeldung das betroffene Feld identifizieren und erklären, wie der Fehler behoben werden kann.

Gut: "Das Feld E-Mail-Adresse enthält eine ungültige Adresse. Beispiel: [email protected]"

Schlecht: "Fehler im Formular" oder nur eine rote Markierung ohne Text

12. Keine Fallen für Tastaturfokus (2.1.2 A)

Der Tastaturfokus darf nicht in einem Element eingeschlossen werden, aus dem der Nutzer nicht mehr herauskommt. Modale Dialoge (Popups) sind ein häufiger Problemfall.

Gut: Beim Öffnen eines Modals geht der Fokus ins Modal. Mit Escape oder einem Schließen-Button kommt man zurück. Der Fokus kehrt nach dem Schließen zum auslösenden Element zurück.

Schlecht: Ein Modal öffnet, aber per Tab-Taste verlässt man das Modal und navigiert den Hintergrundinhalt, der nicht sichtbar ist.

13. Responsive Design und Textvergrößerung (1.4.4 AA)

Text muss auf 200 Prozent vergrößerbar sein, ohne dass Inhalt verloren geht oder Funktionen eingeschränkt werden. Außerdem (1.4.10 AA): Die Seite muss bei 320 CSS-Pixel Viewport-Breite ohne horizontales Scrollen bedienbar sein.

Testen: Stelle den Browser-Zoom auf 200 Prozent und schau, ob alle Inhalte noch lesbar und bedienbar sind.

Häufiger Fehler: Feste Pixel-Werte für Schriftgrößen und Abstände, die keine Skalierung erlauben.

14. Animationen und Bewegung reduzierbar (2.3.3 AAA, aber 2.3.1 A für Anfälle)

Animationen die mehr als 3 Mal pro Sekunde blinken, sind generell verboten (Anfallsrisiko). Für alle anderen Animationen gilt: Wenn ein Nutzer in den Browser-Einstellungen "Bewegung reduzieren" (prefers-reduced-motion) aktiviert, sollten Animationen deaktiviert oder reduziert werden.

@media (prefers-reduced-motion: reduce) {
  * {
    animation: none;
    transition: none;
  }
}

15. Seitentitel (2.4.2 A)

Jede Seite braucht einen eindeutigen, beschreibenden <title>-Tag, der den Inhalt der Seite beschreibt.

Gut: <title>Kontakt | KI-WebSichtbar</title>

Schlecht: <title>Seite</title> oder <title>Startseite</title> ohne den Firmennamen

Typische Verstöße auf KMU-Websites

Aus der Praxis: Das sind die häufigsten Probleme auf KMU-Websites.

Nummer 1: Kein Alt-Text auf Bildern. Der häufigste Verstoß. Oft sind auf einer ganzen Website hunderte Bilder ohne Alt-Text. Das ist ein Level-A-Verstoß, also die unterste Anforderungsstufe.

Nummer 2: Zu wenig Kontrast. Hellgraue Schrift auf weißem Hintergrund sieht modern aus, ist aber unlesbar für Menschen mit Sehschwäche und auch für alle anderen bei Sonnenlicht.

Nummer 3: outline: none im CSS. Ein verbreitetes CSS-Reset-Muster entfernt den Fokusrahmen. Das macht die Website für alle Tastatur-Nutzer (Motorik-Einschränkungen, Power-User, ältere Menschen) schwer bedienbar.

Nummer 4: Formulare ohne Labels. Placeholder-Text ist kein Ersatz für Labels. Bei Google Forms oder einfachen HTML-Formularen passiert das besonders häufig.

Nummer 5: Kein lang-Attribut. Aus einem englischen Template kopiert, nie geändert. Eine Minute Aufwand, ein Level-A-Verstoß vermieden.

Kostenlose Test-Tools

Du brauchst keine teuren Agenturen, um eine erste Prüfung durchzuführen.

Kostenlose Browser-Tools:

• Barrierefreiheit-Check: Unser kostenloses Tool prüft deine URL auf die häufigsten Verstöße. Ideal für eine schnelle Übersicht.
• WAVE (webaim.org/resources/wave/): Browser-Extension, die Barrierefreiheitsfehler direkt auf der Seite markiert. Sehr visuell, gut für Einsteiger.
• Google Lighthouse: Im Chrome-Browser integriert (F12, Reiter "Lighthouse"). Gibt einen Barrierefreiheits-Score und listet Probleme auf.
• axe DevTools: Browser-Extension, genauer als Lighthouse, weniger False Positives.

Kostenlose Prüf-Tools für spezifische Kriterien:

• WebAIM Contrast Checker (webaim.org/resources/contrastchecker/): Kontrastverhältnis berechnen
• Accessible Color Palette Builder (venngage.com): Barrierefreie Farbpaletten erstellen
• Screen Reader: NVDA (Windows, kostenlos), VoiceOver (Mac/iOS, integriert), TalkBack (Android, integriert)

Was automatisierte Tools nicht erkennen:

Automatisierte Tests finden schätzungsweise 30 bis 40 Prozent aller Barrierefreiheitsprobleme. Für vollständige Konformität braucht es manuelle Tests, idealerweise mit echten Nutzern, die Assistenztechnologien verwenden. Das ist für kleine Websites und erste Prüfungen aber kein Anspruch.

Wie du eine bestehende Website barrierefrei machst

Du hast eine bestehende Website und willst nachrüsten. So gehst du strukturiert vor.

Schritt 1: Prüfen, wo du stehst

Nutze den Barrierefreiheit-Check und WAVE für eine erste Übersicht. Notiere dir die gefundenen Probleme und ordne sie nach Level (A vor AA) und Häufigkeit.

Schritt 2: Quick Wins zuerst

Folgende Punkte lassen sich oft in wenigen Stunden beheben:

• lang="de" im HTML-Tag ergänzen
• Alt-Texte für alle Bilder schreiben
• outline: none aus dem CSS entfernen
• Seitentitel einzigartig und beschreibend machen

Schritt 3: Kontrast anpassen

Prüfe die Farb-Kontraste deiner Hauptelemente. Wenn du ein WordPress-Theme nutzt, gibt es oft Farbeinstellungen im Customizer. Bei selbst gecodeten Seiten ist es ein CSS-Wert.

Schritt 4: Formulare überarbeiten

Füge echte Labels zu allen Formularfeldern hinzu und schreibe verständliche Fehlermeldungen.

Schritt 5: Tastaturnavigation testen

Navigiere die gesamte Website nur per Tastatur. Schreibe auf, wo du feststeckst oder den Fokus verlierst.

Schritt 6: Barrierefreiheitserklärung erstellen

Dokumentiere, was du umgesetzt hast, was noch fehlt und wie Nutzer Probleme melden können. Das ist auch eine BFSG-Anforderung.

Mehr Details zur Prüfung bestehender Seiten: Barrierefreiheit Website testen: Tools und Methoden.

Warum statisches HTML barrierefreier ist als WordPress

WordPress-Websites haben ein strukturelles Problem: Themes generieren oft unstrukturierten HTML-Code mit fehlenden Attributen, inkonsistenten Überschriften und JavaScript-abhängigen Komponenten, die für Screenreader problematisch sind. Jedes Plugin bringt eigenen Code mit, der die Barrierefreiheit stören kann.

Statisch gecodetes HTML ist grundsätzlich transparenter. Was du schreibst, wird ausgegeben. Kein Plugin fügt unerwarteten Code ein. Du hast volle Kontrolle über Alt-Texte, Heading-Hierarchie, ARIA-Attribute und Fokus-Verhalten.

Das bedeutet nicht, dass WordPress automatisch unbarrierefrei ist. Aber der Aufwand für vollständige Konformität ist bei statischem HTML deutlich geringer.

Alle Websites bei KI-WebSichtbar werden von Anfang an nach WCAG 2.1 AA gebaut. Barrierefreiheit ist kein Add-on, sondern Teil des Standard-Prozesses. Interessiert? Kostenlose Erstberatung buchen.

Wenn du eine bestehende Website auf BFSG-Konformität prüfen oder deinen Relaunch barrierefrei planen willst, lies zuerst: BFSG 2025: Was Unternehmen jetzt tun müssen.

Und für einen vollständigen Website-Relaunch unter Berücksichtigung aller Anforderungen: Website-Relaunch Checkliste und Professionelles Webdesign: Was es wirklich ausmacht.

---

FAQ: Häufige Fragen zur WCAG-Checkliste

Was ist der Unterschied zwischen WCAG 2.1 und WCAG 2.2?

WCAG 2.2 (Oktober 2023) enthält 9 neue Erfolgskriterien gegenüber WCAG 2.1. Die wichtigsten Neuerungen betreffen sichtbare Fokus-Indikatoren (2.4.11), barrierefreie Authentifizierung (3.3.8) und konsistente Hilfefunktionen (3.2.6). WCAG 2.2 ist abwärtskompatibel: Wer 2.2 AA erfüllt, erfüllt auch 2.1 AA.

Welches WCAG-Level muss ich erfüllen?

Level AA ist der gesetzliche Mindeststandard nach BFSG. Level A ist die Untergrenze ohne die sich Inhalte für manche Nutzer komplett sperren. Level AAA ist eine Empfehlung für Organisationen mit besonders hohen Anforderungen, aber keine allgemeine Pflicht.

Kann ich WCAG-Konformität vollständig mit automatisierten Tools prüfen?

Nein. Automatisierte Tools erkennen schätzungsweise 30 bis 40 Prozent aller Probleme. Alternativtexte werden erkannt (fehlendes Attribut), aber ob der Text sinnvoll ist, können Tools nicht beurteilen. Vollständige Konformitätsprüfung erfordert manuelle Tests.

Wie lange dauert es, eine Website auf WCAG 2.1 AA zu bringen?

Bei einer einfachen Informationswebsite mit sauberem HTML: 4 bis 8 Stunden. Bei einer komplexen Website mit vielen Komponenten, Plugins und altem Code: mehrere Wochen. Wenn die Seite neu gebaut wird: kaum Mehraufwand, wenn Barrierefreiheit von Anfang an mitgedacht wird.

Was passiert, wenn ich WCAG AA nicht erfülle?

Für private B2C-Unternehmen drohen ab Inkrafttreten des BFSG (28. Juni 2025) Bußgelder bis 100.000 EUR und Abmahnungen durch Verbände. Für Behörden und öffentliche Stellen gilt bereits seit Jahren die BITV 2.0 mit ähnlichen Anforderungen.

Muss ich alle WCAG-Kriterien prüfen oder nur die für Websites?

WCAG gilt für Web-Inhalte. Nicht alle Kriterien sind für jede Art von Website gleich relevant. Für eine einfache Informationswebsite ohne Video, ohne komplexe Interaktionen und ohne Authentifizierung ist der relevante Kriterienumfang überschaubar.

Hilft der Compliance-Check auch bei Barrierefreiheit?

Der Compliance-Check prüft vor allem DSGVO- und rechtliche Anforderungen. Für Barrierefreiheit ist der Barrierefreiheit-Check das richtige Tool. Beide gemeinsam decken die wichtigsten gesetzlichen Anforderungen an KMU-Websites ab.