Accessibility‑checkliste für developer: 12 konkrete tests, die deine website barrierefrei machen

Barrierefreiheit ist kein hübsches Extra, sondern Teil guter Entwicklung. In diesem Artikel teile ich mit dir eine praxiserprobte Accessibility‑Checkliste für Developer — 12 konkrete Tests, die ich regelmäßig durchführe, bevor ich eine Website live schalte. Jeder Test enthält eine kurze Erklärung, wie ich ihn mache, welche Tools ich nutze und auf welche Stolperfallen du achten solltest.

Semantisches HTML prüfen

Warum: Semantische Elemente (header, nav, main, article, footer, h1–h6, p, ul/li) geben Screenreadern und Browsern Struktur. Wie ich es mache: Ich scanne das DOM und suche nach falscher Verschachtelung, fehlenden Überschriften oder zu vielen div-Containern. Tools: Lighthouse, axe, manuelle Inspektion im DevTools.

Typische Fehler, auf die ich achte:

• Fehlende <main>-Region
• Mehrere <h1> ohne klaren Kontext (nicht automatisch ein Fehler, aber oft verwirrend)
• Semantische Elemente als Styling-Container missbraucht

Überschriftenstruktur testen

Warum: Eine logische Hierarchie (h1 → h2 → h3 ...) hilft Nutzern, Inhalte zu scannen. Vorgehen: Ich navigiere mit dem Screenreader oder nutze die Accessibility-Tree-Ansicht in den DevTools. Tools: axe, WebAIM’s Headings tool.

Meine Checkpoints:

• Keine Sprünge wie h2 direkt nach h4
• Jede Seite hat eine eindeutige, aussagekräftige h1

Kontraste überprüfen

Warum: Ausreichender Farbkontrast ist essenziell für Menschen mit Sehschwäche. Wie ich es mache: Ich teste kritische Text- und UI-Farben mit Kontrasttools. Tools: WebAIM Contrast Checker, axe, Chrome DevTools Accessibility pane.

Empfehlung: Für normalen Text mindestens ein Kontrastverhältnis von 4.5:1, für großen Text 3:1.

Alt‑Text für Bilder kontrollieren

Warum: Alt-Attribute sind die primäre Beschreibung für Screenreader. Vorgehen: Ich durchsuche Bilder mit fehlendem oder unpassendem alt-Text und frage mich: "Was würde ich sagen, wenn ich dieses Bild beschreiben muss?"

• Bilder mit rein dekorativem Zweck: alt=""
• Bilder mit Inhalt: prägnante Beschreibung, keine redundanten Phrasen wie "Bild von..."

Tastatur-Navigation testen

Warum: Viele Nutzer navigieren ausschließlich mit der Tastatur. Wie ich es mache: Ich bediene die Seite komplett mit Tab, Shift+Tab, Enter, Space, Pfeiltasten und prüfe Fokusreihenfolge, sichtbaren Fokus und erreichbare Interaktionen. Tools: Manuell, Accessibility Insights.

Worauf ich achte:

• Alle interaktiven Elemente sind per Tab erreichbar
• Keine Keyboard‑Fallen (z. B. modale Dialoge ohne Möglichkeit zu schließen)
• Sichtbarer Fokus (outline) ist vorhanden und nicht durch CSS entfernt

Formulare: Labels, Fehler und Tastaturfreundlichkeit

Warum: Forms sind häufige Barrieren. Vorgehen: Ich überprüfe, ob jedes Eingabefeld ein assoziiertes <label> hat, ob Fehlermeldungen klar sind und ARIA-Attribute sinnvoll verwendet werden. Tools: axe, Screenreader (NVDA/VoiceOver).

Checkliste:

• Label ist mit for und id verbunden oder das Feld enthält ein sichtbares Label
• Inline-Fehlermeldungen sind fokussierbar und beschreiben das Problem
• ARIA-DescribedBy wird korrekt eingesetzt, wenn nötig

Fokus-Management und Modale prüfen

Warum: Modal‑Dialoge, Offcanvas-Menüs und dynamische Inhalte müssen den Fokus korrekt verwalten. Wie ich teste: Ich öffne ein Modal mit der Tastatur, prüfe, ob der Fokus ins Modal springt, und ob beim Schließen zum Auslöser zurückkehrt. Tools: axe, manuelle Tests mit Tab/Shift+Tab.

Fehler, die ich oft behebe:

• Fokus bleibt außerhalb des Modals
• Hintergrund bleibt tabbar (focus trapping fehlt)

ARIA sinnvoll einsetzen (nicht missbrauchen)

Warum: ARIA kann Barrieren reduzieren, aber falsche Verwendung schafft neue. Vorgehen: Ich vermeide redundante ARIA-Labels auf bereits semantischen Elementen und nutze Rollen nur wenn nötig. Tools: axe kann ARIA-Fehler aufzeigen.

Gute Praxis: Erst semantisches HTML, dann ARIA, wenn native Elemente nicht ausreichen.

Dynamische Inhalte und Live-Regionen

Warum: Nutzer müssen über asynchrone Änderungen informiert werden (z. B. Validierungsergebnisse, neue Inhalte). Vorgehen: Ich verwende aria-live="polite|assertive" für relevante Updates oder setze beim Austausch von Hauptinhalten den Fokus korrekt. Tools: Screenreader testen, axe.

Medien mit Untertiteln und Transkripten

Warum: Videos und Audio benötigen Texte für Gehörlose und Hörgeschädigte. Wie ich das mache: Ich stelle immer Untertitel (VTT) bereit und, wenn möglich, ein vollständiges Transkript. Tools: YouTube Auto-Captions als Ausgangspunkt, manuelles Korrekturlesen oder Services wie Rev oder Descript.

Zoom- und Responsiveness-Tests

Warum: Nutzer vergrößern Seiten bis 200% oder nutzen verschiedene Bildschirmgrößen. Vorgehen: Ich teste im Browser bei 200% Zoom, in responsiven Layouts und mit Textvergrößerung. Tools: Browser-Zoom, DevTools Device Mode.

Achte auf:

• Keine horizontale Scrollbars bei 200% Zoom
• Layout bricht sinnvoll um, Buttons bleiben erreichbar

Screenreader-Tests

Warum: Automatisierte Tools finden viele Probleme, aber nicht alle. Ich nutze NVDA (Windows) und VoiceOver (macOS/iOS), um Interaktionen aus Nutzersicht zu prüfen. Vorgehen: Ich navigiere Seiten strukturiert, lese Überschriftenliste, Formulare und dynamische Updates vor.

Tipps:

• NVDA ist kostenlos und sehr aussagekräftig
• Teste sowohl Desktop- als auch Mobile-Varianten

Automatisierte Audit-Tools einsetzen

Warum: Automatisierte Tools sind schnell und verhindern Regressionen. Welche ich nutze:

• Lighthouse (Chrome) für einen schnellen Überblick
• axe-core / axe DevTools für detaillierte Fehlerberichte
• pa11y für CI-Checks
• Accessibility Insights für tiefere Analysen

Wichtig: Automatische Tests decken nur ~30–50% der Probleme ab. Combine them with manual checks.

Praktische Checkliste (Kurzversion)

Wenn du möchtest, kann ich dir auch eine druckbare Checkliste im Markdown- oder PDF-Format erstellen, die du in deinem CI/CD-Prozess verwenden kannst — inklusive Befehlen für pa11y und axe‑cli. Sag mir kurz, welche Tools in deinem Team genutzt werden (z. B. React, Vue, WordPress), dann passe ich die Liste an typische Fallstricke dieser Plattformen an.