Barrierefreie Websites technisch umsetzen: WCAG 2.2
Barrierefreie Frontends machen Inhalte und Funktionen mit Tastatur, Screenreader und Vergrößerung nutzbar. Die WCAG 2.2 ordnen die Anforderungen nach vier Prinzipien: wahrnehmbar, bedienbar, verständlich und robust.
Technik trägt einen Teil der Arbeit. Redaktion, Design, Entwicklung und Qualitätssicherung prüfen dieselben Seitentypen gemeinsam.
Semantisches HTML bildet die Grundlage
HTML-Elemente beschreiben die Funktion eines Inhalts. Überschriften gliedern Abschnitte. Listen kennzeichnen Aufzählungen. Links führen zu einem Ziel. Buttons lösen eine Aktion aus. Formularfelder erhalten eine Beschriftung.
Native Elemente bringen ihre Funktion mit. Ein <button> reagiert auf Tastatureingaben und übermittelt seine Rolle an assistive Technik. Ein allgemeines <div> verlangt diesen Ablauf erst durch zusätzlichen Code.
Die erste ARIA-Regel verlangt native HTML-Elemente.
Seitenstruktur prüfen
Die technische Prüfung erfasst mindestens:
| Element | Prüfpunkt |
|---|---|
| Sprache | Das Dokument nennt seine Hauptsprache mit lang. |
| Regionen | header, nav, main und footer gliedern die Bereiche. |
| Überschriften | Ebenen folgen der Inhaltsstruktur. |
| Links | Linktext beschreibt das Ziel im Kontext. |
| Buttons | Beschriftung beschreibt die ausgelöste Aktion. |
| Listen | Zusammengehörige Punkte stehen in Listenelementen. |
| Tabellen | Kopfzellen und Beziehungen sind ausgezeichnet. |
Semantik hilft auch Suchmaschinen, Inhalte zu verarbeiten. Daraus folgt keine Rankinggarantie.
Tastaturzugang und Fokus sichern
Tastaturnutzer erreichen alle interaktiven Funktionen ohne Maus. Die Fokusreihenfolge folgt dem sichtbaren Dokumentpfad.
Sichtbaren Fokus erhalten
Ein fokussiertes Element verlangt eine sichtbare Markierung. CSS darf den Browserfokus nicht löschen, ohne einen gleichwertigen Ersatz zu setzen.
:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 3px;
}
Die Farbe muss zum Hintergrund passen. Ein globales outline: none nimmt Tastaturnutzern die Orientierung.
Fokus bei Dialogen steuern
Ein Dialog setzt den Fokus beim Öffnen an eine Stelle im Fenster, hält die Navigation im Modalfenster und gibt den Fokus nach dem Schließen an den Auslöser zurück. Das Team prüft Escape-Verhalten und Beschriftung mit Tastatur und Screenreader.
Sprunglink anbieten
Ein Sprunglink führt direkt zum Hauptinhalt. Er spart wiederholte Tastaturklicks über große Kopfbereiche.
<a class="skip-link" href="#main">Zum Hauptinhalt</a>
<main id="main">…</main>
Formulare verständlich bauen
Jedes Eingabefeld braucht eine sichtbare Beschriftung. Platzhalter ersetzen kein Label, weil sie beim Tippen verschwinden und zu wenig Kontrast bieten.
Fehlermeldungen nennen das betroffene Feld und die verlangte Korrektur. Farbe allein reicht nicht als Signal.
<label for="email">E-Mail-Adresse</label>
<input id="email" name="email" type="email" aria-describedby="email-help email-error">
<p id="email-help">Für die Antwort auf deine Anfrage.</p>
<p id="email-error">Bitte gib eine gültige E-Mail-Adresse ein.</p>
Bei dynamischen Formularen prüfst du zusätzlich, ob assistive Technik neue Fehlermeldungen meldet und wo der Fokus nach dem Absenden landet.
Bilder, Audio und Video zugänglich machen
Alternativtexte nach Zweck schreiben
Ein Alternativtext beschreibt Information oder Funktion eines Bildes. Ein dekoratives Bild erhält einen leeren Alternativtext (alt=""). Ein verlinktes Bild beschreibt das Linkziel. Komplexe Diagramme verlangen neben einer kurzen Alternative eine Erklärung im Fließtext.
Dateiname, Bildunterschrift und Alternativtext erfüllen verschiedene Aufgaben. Das System setzt sie nicht gleich.
Audio und Video ergänzen
Aufgezeichnete Videos verlangen je nach Inhalt Untertitel, Audiodeskription oder eine Textalternative. Autoplay mit Ton erschwert die Kontrolle und überlagert die Sprachausgabe.
Lade Medien nur in der benötigten Qualität und Größe. Das senkt den Datentransfer, ersetzt aber keine Emissionsmessung.
Kontrast, Vergrößerung und Bewegung prüfen
Text und Bedienelemente brauchen ausreichenden Kontrast. WCAG 2.2 nennt für normalen Text ein Verhältnis von mindestens 4,5:1 und für großen Text 3:1. Für Komponenten und Grafikobjekte gelten eigene Maßstäbe.
Die Prüfung erfasst Fließtext und Systemzustände: Auch Hover-, Fokus-, Fehler- und Dark-Mode-Zustände bleiben lesbar.
Layouts schneiden Inhalte bei Vergrößerung oder schmaler Breite nicht ab. Lesende passen Textabstände an, ohne Funktionen zu verlieren.
Animationen respektieren die Systemeinstellung für reduzierte Bewegung:
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
scroll-behavior: auto;
animation-duration: 0.01ms;
animation-iteration-count: 1;
transition-duration: 0.01ms;
}
}
Die technische Umsetzung eines Dark Mode behandelt Farbmodi und Nutzerpräferenz gesondert im Beitrag Dark Mode und OLED-Energieeffizienz.
Barrierefreiheit und Performance getrennt messen
Einige Maßnahmen dienen beiden Zielen. Native Elemente sparen Zusatzcode. Eine organisierte Navigation verkürzt Bedienwege. Kleine Medien senken Datentransfer.
Diese Überschneidung belegt nicht, dass jede barrierefreie Maßnahme Energie spart. Ein Accessibility-Test misst Nutzbarkeit nach Kriterien. Eine Nachhaltigkeitsprüfung misst Datenvolumen oder andere feste Größen. Beide Prüfungen verlangen eigene Ergebnisse.
Der Beitrag Werkzeuge für Core Web Vitals und mobile Nutzbarkeit ordnet Labor- und Felddaten ein. Die W3C Web Sustainability Guidelines liefern einen separaten Rahmen für nachhaltige Webentwicklung.
Rechtlichen Geltungsbereich separat prüfen
Der European Accessibility Act und das deutsche Barrierefreiheitsstärkungsgesetz betreffen bestimmte Produkte und Dienstleistungen. Ob eine Website, ein Betrieb oder ein Angebot darunter fällt, hängt von Geltungsbereich und Ausnahmen ab.
Eine WCAG-Prüfung ersetzt keine Rechtsberatung. Die technische Dokumentation unterscheidet deshalb zwischen:
- →erfülltem technischen Kriterium,
- →gefundenem Fehler,
- →nicht geprüftem Seitentyp,
- →rechtlicher Einordnung durch eine zuständige Stelle.
So wird Barrierefreiheit geprüft
Automatische Werkzeuge finden einen Teil der Fehler. Sie markieren fehlende Labels, Kontrastprobleme oder ungültige Rollen. Ob ein Alternativtext seinen Zweck erfüllt oder ein Bedienablauf verständlich bleibt, entscheiden sie nicht.
Ein Prüfplan kombiniert:
- →automatisierte Tests
- →Tastaturprüfung
- →Prüfung mit Screenreader
- →Vergrößerung und Reflow
- →Kontrast und Zustände
- →Manuelle Aufgabenprüfung bei hohem Risiko
Abnahme pro Seitentyp
| Prüffeld | Abnahmekriterium |
|---|---|
| Struktur | Regionen und Überschriften bilden den Inhalt ab |
| Tastatur | Jede Funktion ist erreichbar und bedienbar |
| Fokus | Fokus bleibt sichtbar und folgt einer logischen Reihenfolge |
| Formulare | Labels, Hinweise und Fehler sind zugeordnet |
| Medien | Alternativen entsprechen dem Zweck |
| Ansicht | Zoom, schmale Breite und Textabstände brechen keine Funktion |
| Bewegung | Nutzerpräferenz für reduzierte Bewegung wird beachtet |
| Dokumentation | Geprüfte Seiten, Werkzeuge und offene Punkte sind genannt |
Der Beitrag User Experience (UX) als Rankingfaktor ordnet die Nutzungsperspektive ein. Die Redaktionelle SEO prüft Quellen und Verantwortung der Inhalte.
Häufige Fragen zur Barrierefreiheit
Reicht ein automatischer Accessibility-Score?
Nein. Automatische Tests erfassen nur maschinell prüfbare Kriterien. Tastatur, Screenreader, Sprachfluss und Aufgabenlogik verlangen manuelle Prüfschritte.
Muss jede Komponente ARIA verwenden?
Nein. Native HTML-Elemente bieten das stabilste Fundament. ARIA ergänzt fehlende Semantik, repariert aber keine fehlerhafte Tastaturbedienung.
Verbessert Barrierefreiheit automatisch Rankings?
Nein. Barrierefreiheit strukturiert Dokumente und verbessert die Nutzbarkeit. Eine feste Suchposition garantiert sie nicht.
Spart eine barrierefreie Seite automatisch Energie?
Nein. Einzelne Maßnahmen senken den Datentransfer. Aussagen zu Energie oder Emissionen verlangen eine eigene Messmethode.
Nächster Schritt
Der Beitrag Technisches SEO: Infrastruktur, Architektur und Jamstack ordnet Barrierefreiheit in die Webarchitektur ein. Für einen statischen Unternehmensauftritt verbindet OLDSCHOOLSEO Inhalt, Frontend und Auslieferung in einer Jamstack-Website ab 224 €.
Projektanfrage per E-Mail senden · Erstgespräch mit Sandra buchen
▋
Sandra Krone ist Partnerin und Gründerin von OLDSCHOOLSEO. Ihre Arbeit beginnt bei der Analyse der Nutzerintention und der Content-Strategie, um daraus die Anforderungen für die redaktionelle und technische Umsetzung abzuleiten.