Website-Barrierefreiheit: Ein praktischer WCAG-2.2-Leitfaden
Wie man WCAG 2.2 für die eigene Website liest, die Korrekturen, die die meisten realen Fehler abdecken, ein 30-minütiger manueller Test, den jeder durchführen kann, und wie sich Barrierefreiheit und Usability überschneiden.
Häufige Fragen
Was bedeutet es, dass eine Website WCAG-konform ist?
Es bedeutet, dass die Website die Erfolgskriterien der Web Content Accessibility Guidelines auf einer gewählten Stufe erfüllt, meist WCAG 2.1 oder 2.2 Stufe AA. Stufe AA umfasst jedes Kriterium der Stufen A und AA. Die meisten Gesetze und Beschaffungsrichtlinien, die auf WCAG verweisen, verlangen Stufe AA.
Wie sollte ich WCAG-Richtlinien für meine Website interpretieren?
Beginnen Sie mit der Kurzreferenz „How to Meet WCAG" des W3C, filtern Sie auf Stufe A und AA, und lesen Sie für jedes Kriterium die „Understanding"-Seite, die die Absicht in einfacher Sprache erklärt. Testen Sie dann Ihre zentralen Vorlagen (Start, eine Inhaltsseite, ein Formular, Checkout) statt jede Seite einzeln.
Kann ein Barrierefreiheits-Overlay oder Plugin meine Website konform machen?
Kein Tool kann eine Website allein konform machen. Overlays, die eine Toolbar hinzufügen, beheben nicht den zugrunde liegenden Code, und viele Menschen mit Behinderungen und Barrierefreiheits-Spezialisten berichten, dass sie im Weg stehen. Beheben Sie HTML, Kontrast, Beschriftungen und Tastaturunterstützung direkt.
Was ist der Unterschied zwischen Usability und Barrierefreiheit?
Barrierefreiheit bedeutet, dass Menschen mit Behinderungen die Website wahrnehmen, verstehen, navigieren und mit ihr interagieren können. Usability bedeutet, dass die Website für alle leicht und effizient ist. Sie überschneiden sich stark: klare Beschriftungen, guter Kontrast und vorhersehbare Navigation helfen allen Besuchern, nicht nur Menschen mit Behinderungen.
Finden automatisierte Prüfer alle Barrierefreiheitsprobleme?
Nein. Tools wie WAVE, axe und Lighthouse erfassen Probleme wie fehlenden Alt-Text, niedrigen Kontrast und fehlende Beschriftungen, aber viele Kriterien, wie ob Alt-Text aussagekräftig ist oder ob die Fokusreihenfolge Sinn ergibt, brauchen einen Menschen zur Prüfung.
Eine WCAG-konforme Website erfüllt die Web Content Accessibility Guidelines auf einer gewählten Stufe, und für fast jedes Unternehmen bedeutet das WCAG 2.2 Stufe AA. In der Praxis scheitern die meisten Websites an derselben Handvoll Probleme: niedriger Farbkontrast, fehlender Bild-Alt-Text, unbeschriftete Formularfelder, leere Links und Buttons, und Dinge, die Sie nicht mit der Tastatur erreichen können. Beheben Sie diese und testen Sie mit Tastatur und Screenreader, und Sie haben einen großen Teil dessen abgedeckt, worauf echte Nutzer treffen.
Dieser Leitfaden erklärt, wie man WCAG liest, ohne den Überblick zu verlieren, die Korrekturen, die am meisten zählen, und einen Test, den Sie in 30 Minuten selbst machen können.
Wie WCAG strukturiert ist
WCAG wird vom W3C veröffentlicht. Es ist in Schichten organisiert:
Vier Prinzipien, bekannt als POUR: Inhalt muss Wahrnehmbar (Perceivable), Bedienbar (Operable), Verständlich (Understandable) und Robust sein.
Richtlinien unter jedem Prinzip (zum Beispiel „Textalternativen" oder „Tastaturzugänglich").
Erfolgskriterien unter jeder Richtlinie. Das sind die testbaren Regeln, jede nummeriert (etwa 1.4.3 Kontrast) und einer Stufe zugeordnet: A, AA oder AAA.
Stufe A ist das Minimum. Stufe AA ist das übliche Ziel für rechtliche und Beschaffungsanforderungen. Stufe AAA ist strenger und wird normalerweise nicht für ganze Websites verlangt.
WCAG 2.2 wurde im Oktober 2023 zur W3C-Empfehlung. Es fügte Kriterien wie Mindestzielgröße, ungestörten Fokus und barrierefreie Authentifizierung hinzu, und entfernte 4.1.1 Parsing als veraltet.
Wie man WCAG für die eigene Website interpretiert
Die Spezifikation liest sich wie ein Standard, weil sie einer ist. Ein praktischer Weg hindurch:
Öffnen Sie die „How to Meet WCAG (Quick Reference)" des W3C.
Filtern Sie sie auf Stufe A und AA allein.
Lesen Sie für jedes Kriterium die verlinkte „Understanding"-Seite. Sie erklärt die Absicht in einfacher Sprache, mit Beispielen für Bestehen und Scheitern.
Testen Sie statt jeder Seite Ihre Vorlagen: Startseite, eine Standard-Inhaltsseite, ein Blogbeitrag, ein Formular, eine Produkt- oder Checkout-Seite. Eine Vorlage zu reparieren repariert jede darauf gebaute Seite.
Protokollieren Sie jedes Problem mit Kriteriumsnummer, Seite und wie eine Korrektur aussieht.
Die Korrekturen, die die meisten realen Fehler abdecken
1. Farbkontrast (1.4.3 und 1.4.11)
Normaler Text: mindestens 4,5:1 gegen den Hintergrund.
Großer Text (etwa 24px normal, oder 18,66px fett und größer): mindestens 3:1.
Interface-Komponenten und bedeutsame Grafiken (Button-Ränder, Eingabe-Umrisse, Symbole, die Informationen vermitteln): mindestens 3:1.
Hellgrauer Platzhaltertext und weißer Text auf blassen Markenfarben sind die üblichen Übeltäter. Prüfen Sie mit WebAIMs Kontrast-Checker oder den Entwicklertools Ihres Browsers.
2. Textalternativen für Bilder (1.1.1)
Informative Bilder bekommen Alt-Text, der das Wichtige beschreibt: alt="Techniker wechselt einen Ofenfilter".
Dekorative Bilder bekommen leeren Alt: alt="", damit Screenreader sie überspringen.
Bilder von Text (ein Flyer-Screenshot, eine Speisekarte als JPG) brauchen denselben Text auch als echten Text.
Verlinkte Bilder, etwa ein Logo, das zur Startseite führt, beschreiben das Ziel: alt="Acme Plumbing Startseite".
3. Formularbeschriftungen und Fehler (1.3.1, 3.3.1, 3.3.2)
Jede Eingabe braucht ein sichtbares, verknüpftes <label>. Platzhaltertext ist keine Beschriftung: er verschwindet beim Tippen.
Fehlermeldungen sagen, was schiefging und wie man es behebt („Geben Sie eine Telefonnummer mit Vorwahl ein"), als Text, nicht nur als roter Rahmen.
Pflichtfelder sind im Text oder mit einem barrierefreien Indikator markiert, nicht nur durch Farbe.
4. Tastaturzugriff (2.1.1, 2.4.3, 2.4.7)
Jeder Link, Button, jedes Menü und Formularelement muss mit Tab, Shift+Tab, Enter und Leertaste funktionieren.
Die Fokusreihenfolge folgt der visuellen Reihenfolge.
Ein sichtbarer Fokusindikator zeigt, wo Sie sind. Das Entfernen des Browser-Umrisses mit outline: none ohne Ersatz ist ein häufiger Fehler.
Dropdown-Menüs und Modals müssen sich per Tastatur öffnen, funktionieren und schließen lassen, und Modals sollten den Fokus innen halten, bis sie geschlossen werden.
5. Links und Buttons mit Namen (2.4.4, 4.1.2)
Nur-Symbol-Buttons (ein Hamburger-Menü, eine Such-Lupe, Social-Icons) brauchen einen barrierefreien Namen, über sichtbaren Text, aria-label oder verstecktem Text.
Vermeiden Sie eine Seite voller „Hier klicken"- und „Weiterlesen"-Links. Lassen Sie Linktext das Ziel beschreiben, oder geben Sie jedem einen eigenen barrierefreien Namen.
6. Struktur und Überschriften (1.3.1, 2.4.6)
Ein <h1> pro Seite, das die Seite beschreibt.
Überschriften in logischer Reihenfolge (h2 für Abschnitte, h3 darin), nicht nach Schriftgröße gewählt.
Nutzen Sie echte Listen, Tabellen mit Kopfzellen, und Landmarken (<header>, <nav>, <main>, <footer>).
Setzen Sie die Seitensprache: <html lang="de">.
7. Neu in WCAG 2.2, wissenswert
2.5.8 Zielgröße (Minimum), AA: klickbare Ziele mindestens 24 mal 24 CSS-Pixel, oder genug Abstand um kleinere.
2.4.11 Fokus nicht verdeckt (Minimum), AA: klebende Header, Cookie-Banner und Chat-Widgets dürfen das fokussierte Element nicht vollständig verdecken.
3.3.8 Barrierefreie Authentifizierung (Minimum), AA: verlangen Sie nicht, Rätsel zu lösen oder sich Informationen zu merken, um sich ohne Alternative einzuloggen; erlauben Sie Passwort-Manager und Einfügen.
3.3.7 Redundante Eingabe, A: lassen Sie Menschen nicht Informationen erneut eintippen, die sie im selben Prozess bereits gegeben haben.
8. Medien und Bewegung
Videos brauchen Untertitel (1.2.2); vorab aufgezeichnetes Video braucht Audiodeskription oder eine Textalternative für wichtigen visuellen Inhalt.
Alles, was sich automatisch länger als fünf Sekunden bewegt, braucht eine Pausiermöglichkeit (2.2.2).
Respektieren Sie die Einstellung prefers-reduced-motion für große Animationen.
Ein 30-minütiger manueller Test
Automatisierte Tools erfassen nur einen Teil des Bildes. Fügen Sie diese Routine für jede zentrale Vorlage hinzu.
Minuten 0 bis 5: automatischer Scan. Führen Sie WAVE (Browser-Erweiterung) oder axe DevTools aus, oder den Barrierefreiheitsbereich von Lighthouse. Beheben Sie klare Fehler wie fehlenden Alt-Text, fehlende Beschriftungen und Kontrastfehler.
Minuten 5 bis 15: nur Tastatur. Legen Sie die Maus weg. Tabben Sie sich von oben durch die Seite.
Sehen Sie jederzeit, wo der Fokus ist?
Können Sie das Menü öffnen und schließen, jedes Formularfeld nutzen und absenden?
Gibt es einen „Zum Inhalt springen"-Link, und funktioniert er?
Verschwindet der Fokus je hinter einem klebenden Header oder Banner?
Minuten 15 bis 25: Screenreader. Nutzen Sie VoiceOver (in macOS und iOS integriert) oder NVDA (kostenlos für Windows).
Hören Sie sich die Überschriftenliste an. Beschreibt sie die Seite?
Tabben Sie zu Bildern und Buttons. Ergeben sie außerhalb des Kontexts Sinn?
Füllen Sie das Formular aus. Wird jedes Feld mit seiner Beschriftung angesagt? Werden Fehler angesagt?
Minuten 25 bis 30: Zoom und Reflow. Zoomen Sie den Browser auf 200% und dann 400%. Bei 400% sollte sich der Inhalt ohne horizontales Scrollen in eine Spalte umbrechen (1.4.10 Reflow), und nichts sollte abgeschnitten sein.
Überschneidung von Usability und Barrierefreiheit
Menschen, die nach „Web-Usability Barrierefreiheit" suchen, haben recht, sie zusammenzufassen. Fast jede Barrierefreiheitskorrektur ist eine Usability-Korrektur:
Barrierefreiheitskorrektur
Wem sie sonst noch hilft
Starker Kontrast
Jedem auf dem Handy im Sonnenlicht
Sichtbare Beschriftungen
Jedem, der in Eile ein Formular ausfüllt
Untertitel
Menschen, die mit ausgeschaltetem Ton schauen
Tastaturunterstützung
Power-Usern, Menschen mit kaputtem Trackpad
Größere Tap-Ziele
Allen auf Mobilgeräten
Klare Fehlermeldungen
Jedem, der sich vertippt
Overlays, Erklärungen und das Gesetz
Overlays: Widgets, die Konformität in einer Zeile versprechen, ändern Ihren zugrunde liegenden Code nicht. Reparieren Sie die Website selbst.
Barrierefreiheitserklärung: Veröffentlichen Sie eine kurze Seite, die sagt, welchen Standard Sie anstreben, bekannte Probleme, und wie man Sie für Hilfe oder alternative Formate kontaktiert.
Rechtlicher Kontext: Anforderungen variieren nach Land. Der European Accessibility Act gilt ab Juni 2025 für viele Produkte und Dienstleistungen in der EU; in den USA wird der ADA häufig auf Websites angewendet; öffentliche Stellen haben oft spezifische Regeln. Holen Sie Rechtsberatung für Ihre Situation ein.
Checkliste
[ ] Kontrast: 4,5:1 Text, 3:1 großer Text und UI-Teile
[ ] Alt-Text bei informativen Bildern, leerer Alt bei dekorativen
[ ] Jede Eingabe hat eine sichtbare, verknüpfte Beschriftung
[ ] Gesamte Website funktioniert per Tastatur mit sichtbarem Fokus
[ ] Symbol-Buttons haben barrierefreie Namen
[ ] Logische Überschriften und Landmarken, Seitensprache gesetzt
[ ] Tap-Ziele mindestens 24 mal 24 CSS-Pixel
[ ] Untertitel bei Video, Pausiersteuerung bei Bewegung
[ ] Bricht bei 400% Zoom um
[ ] Barrierefreiheitserklärung veröffentlicht
Barrierefreiheit unterstützt auch die Suche: Überschriften, Alt-Text und beschreibende Links sind auch On-Page-SEO-Grundlagen, behandelt in unserer On-Page-SEO-Checkliste.
We.Inc erzeugt Websites als Standard-HTML-, CSS- und React-Code, den Sie direkt bearbeiten können, Sie können also Beschriftungen, Alt-Text und Kontrast selbst reparieren oder im Chat um die Änderungen bitten. Führen Sie die manuellen Prüfungen oben immer bei allem durch, was Sie veröffentlichen.