EMZETT.Barrierefreiheit (Accessibility, kurz a11y) bedeutet, dass Menschen mit unterschiedlichen Fähigkeiten deine Seite nutzen können: blinde Menschen mit Screenreader, Menschen mit Sehschwäche, Gehörlose, Menschen mit motorischen Einschränkungen (nur Tastatur) und viele mehr. Davon profitieren alle, etwa wer ein Handy im Sonnenlicht nutzt.
In Deutschland und der EU ist Barrierefreiheit für viele Angebote gesetzlich vorgeschrieben (Barrierefreiheitsstärkungsgesetz, seit Juni 2025). Grundlage sind die WCAG (Web Content Accessibility Guidelines) mit den Prinzipien: wahrnehmbar, bedienbar, verständlich, robust.
Die wichtigsten Regeln
- Semantisches HTML verwenden (
button,a,nav,main,h1bish6,label) - Alternativtexte für Bilder (
alt), Untertitel für Video - Genug Kontrast (mindestens 4,5:1 für normalen Text)
- Alles per Tastatur bedienbar, mit sichtbarem Fokus
- Nicht nur Farbe als Information (zusätzlich Text oder Symbol)
- Klare Sprache und sinnvolle Überschriften
- Seiteninhalte bei 200 % Zoom nutzbar
Tastaturbedienung
Probiere deine Seite nur mit Tab, Shift+Tab, Enter, Leertaste und den Pfeiltasten. Kommst du überall hin? Siehst du, wo der Fokus ist?
Ergebnis
- Nimm
<button>für Aktionen und<a href>für Navigation. Sie sind automatisch fokussierbar und per Tastatur bedienbar. tabindex="0"macht ein Element fokussierbar,tabindex="-1"nur per Skript. Positive Werte (tabindex="3") vermeiden.- Entferne den Fokusrahmen nie ohne gleichwertigen Ersatz.
Kontrast
Ergebnis
Werkzeuge: der Kontrast-Rechner in den Browser-Entwicklerwerkzeugen oder die Seite webaim.org/resources/contrastchecker.
ARIA: nur wenn nötig
ARIA (Accessible Rich Internet Applications) ergänzt Informationen für Hilfstechnologien, wenn HTML allein nicht reicht. Die erste Regel lautet: Nutze zuerst natives HTML. Ein <button> braucht kein role="button".
| Attribut | Zweck | Beispiel |
|---|---|---|
aria-label | Name, wenn kein sichtbarer Text da ist | <button aria-label="Menü schließen">×</button> |
aria-labelledby | Name aus anderem Element | Dialog über seine Überschrift benennen |
aria-describedby | Zusatzbeschreibung | Fehlertext zum Feld |
aria-expanded | auf-/zugeklappt | Menü- und Akkordeon-Knöpfe |
aria-current | aktuelle Seite/Schritt | aria-current="page" |
aria-live | Änderungen ankündigen | role="status", role="alert" |
aria-hidden="true" | vor Screenreadern verbergen | Dekoration |
role | Rolle | role="tablist" bei eigenen Widgets |
Ergebnis
Formulare
- Jedes Feld hat ein
<label> - Fehlermeldungen als Text, verknüpft mit
aria-describedby, bei ungültigen Feldernaria-invalid="true" - Pflichtfelder im Label kennzeichnen ("Name (Pflicht)")
- Autovervollständigung mit
autocompleteerleichtert vielen Menschen die Eingabe
Bewegung und Medien
prefers-reduced-motionrespektieren und Animationen dann reduzieren (siehe CSS-Kapitel)- Nichts blinkt oder bewegt sich länger als 5 Sekunden ohne Pausemöglichkeit
- Videos mit Untertiteln, Audio mit Transkript
Testen
- Tastatur: komplette Seite ohne Maus bedienen
- Screenreader ausprobieren: NVDA (Windows, kostenlos), VoiceOver (Mac/iPhone), TalkBack (Android)
- Automatische Tests: Lighthouse (in Chrome), axe DevTools, WAVE. Sie finden etwa ein Drittel der Probleme
- Zoom auf 200 %, Textgröße vergrößern, Hochkontrast-Modus
- Echte Nutzerinnen und Nutzer fragen
Merke
- Natives, semantisches HTML ist die Basis der Barrierefreiheit
- Alt-Texte, Labels, Überschriften, Kontrast, sichtbarer Fokus
- Alles muss per Tastatur gehen
- ARIA nur ergänzend und korrekt
- Teste mit Tastatur, Screenreader und Werkzeugen wie Lighthouse
Aufgabe
Prüfe eine eigene Seite nur mit der Tastatur und mit Lighthouse. Notiere drei Probleme und behebe sie.