Barrierefreie Websites: 8 Checks, die im Frontend den Unterschied machen

Barrierefreiheit ist keine kosmetische Korrektur am Ende eines Projekts. Sie beeinflusst Struktur, Interaktion und Verständlichkeit eines digitalen Produkts. Wiederholbare Prüfungen im Frontend helfen, Probleme früh zu finden.

1. Die Website per Tastatur bedienen

Navigiere ausschließlich mit Tab, Shift+Tab, Enter, Leertaste und den Pfeiltasten. Alle interaktiven Elemente müssen erreichbar sein; der Fokus muss sichtbar bleiben. Dialoge sollten den Fokus sinnvoll führen und nach dem Schließen an die vorherige Stelle zurückgeben.

2. Semantische Elemente verwenden

Verwende echte Buttons für Aktionen und Links für Navigation. Überschriften brauchen eine nachvollziehbare Hierarchie. Eine anklickbare `div` benötigt zusätzliche Rollen, Tastaturverhalten und einen zugänglichen Namen – ein echter Button bringt diese Semantik bereits mit.

3. Jedes Feld braucht ein Label

Ein Platzhalter ersetzt kein Label. Verknüpfe Beschriftung und Eingabe über `htmlFor` und `id`. Der Zweck darf nicht allein durch Farbe oder Icon vermittelt werden. Pflichtfelder sollten verständlich markiert sein.

4. Fehler klar erklären

Zeige die Fehlermeldung nahe am betroffenen Feld und erkläre die nächste Handlung. Technische Meldungen wie „Invalid input“ helfen wenig. Neue Meldungen müssen auch für Screenreader erkennbar sein, etwa über geeignete Live-Regionen.

5. Kontrast und Fokus prüfen

Prüfe Text, Icons, Grenzen und Fokusindikatoren nicht nur im Normalzustand, sondern auch bei Hover, Fokus, Disabled und Fehlern. Besonders dünne farbige Ringe auf dunklen Flächen sind oft schwer erkennbar.

6. Icon-Buttons benennen

Ein Icon-only-Button benötigt einen zugänglichen Namen wie „Suche öffnen“. Dekorative SVGs sollten für Screenreader verborgen werden. Ein Tooltip allein ersetzt den zugänglichen Namen nicht zuverlässig.

7. Bewegung respektvoll einsetzen

Respektiere `prefers-reduced-motion`, halte Übergänge kurz und stelle sicher, dass Inhalte auch ohne Animation erreichbar sind. Ein wichtiges Heading sollte nicht erst nach einer langen Einblendsequenz sichtbar werden.

8. Mit realen Nutzungsmustern testen

Automatisierte Audits sind ein guter Start, entdecken aber nicht alles. Prüfe die Seite zusätzlich per Tastatur, bei Browser-Zoom und auf schmalen Bildschirmen. Ein Screenreader-Test deckt weitere Probleme in Formularen, Menüs und Dialogen auf.

Baue diese Punkte in Code Reviews und gemeinsame UI-Komponenten ein. Wenn Buttons, Dialoge und Eingabefelder bereits zugänglich sind, profitieren alle Seiten, die sie verwenden. Barrierefreiheit macht Produkte verständlicher, robuster und in mehr Situationen nutzbar.

**Über den Autor:** Casian Blanaru verbindet UI/UX, Webentwicklung und barrierearme Frontends bei PixelCoda.