Web-Accessibility-Grundlagen, die jedes Team ausliefern sollte

Accessibility wird oft als Spezialthema für Compliance-Audits behandelt – und genau das bringt Teams dazu, gar nichts zu tun. Die Wahrheit ist: Eine Handvoll Grundlagen deckt den Großteil der realen Anforderungen ab. Sie lassen sich von Anfang an günstig einbauen und machen das Produkt für alle besser – nicht nur für Nutzer mit Beeinträchtigungen. Hier ist die Baseline, die jedes Team ausliefern sollte, in Prioritätsreihenfolge.

Mit semantischem HTML beginnen

Die wichtigste Entscheidung für Accessibility ist, das richtige HTML-Element für den jeweiligen Zweck zu verwenden. Ein <button> ist fokussierbar, per Tastatur bedienbar und wird von Screenreadern kostenlos korrekt ausgegeben. Ein <div> mit einem Click-Handler bietet nichts davon.

• <button> für Aktionen verwenden, <a> für Navigation – niemals ein gestyltes <div>
• Überschriften (<h1>–<h6>) in der richtigen Reihenfolge einsetzen, um Struktur zu vermitteln
• Landmarks wie <nav>, <main>, <header> und <footer> nutzen
• Echte <label>-Elemente verwenden, die mit ihren Eingabefeldern verknüpft sind

Wer das konsequent umsetzt, hat die meisten Accessibility-Probleme gelöst, bevor auch nur eine Zeile ARIA geschrieben wurde.

Alles per Tastatur bedienbar machen

Viele Nutzer navigieren ausschließlich per Tastatur. Tabben Sie durch Ihre gesamte Anwendung und prüfen Sie zwei Dinge: Können alle interaktiven Elemente erreicht und aktiviert werden – und ist immer sichtbar, wo der Fokus liegt? Ein sichtbarer Fokusring ist keine Kür; entfernen Sie den Outline niemals, ohne ihn durch etwas Klareres zu ersetzen.

Achten Sie auf Keyboard-Traps (Fokus, der in einem Modal stecken bleibt), benutzerdefinierte Dropdowns, die Pfeiltasten ignorieren, und Click-Handler auf nicht fokussierbaren Elementen.

Kontrast und Text korrekt umsetzen

Zu geringer Kontrast ist der häufigste Accessibility-Fehler – und trivial zu beheben. Streben Sie ein Kontrastverhältnis von mindestens 4.5:1 für Fließtext und 3:1 für großen Text an. Verlassen Sie sich nicht allein auf Farbe, um Bedeutung zu transportieren – ein Fehlerzustand braucht ein Icon oder einen Text, nicht nur Rot.

Erlauben Sie Nutzern, Zoom und Textgröße anzupassen, ohne dass das Layout bricht, und deaktivieren Sie niemals den Pinch-to-Zoom auf mobilen Geräten.

Bilder und dynamische Inhalte korrekt behandeln

• Informative Bilder erhalten aussagekräftigen alt-Text; dekorative Bilder erhalten leeres alt="", damit Screenreader sie überspringen
• Dynamische Aktualisierungen (Toasts, Live-Validierung) über eine aria-live-Region ankündigen, damit Screenreader-Nutzer sie wahrnehmen
• Sicherstellen, dass Modals den Fokus korrekt einfangen und zurückgeben

ARIA sparsam und korrekt einsetzen

ARIA ermöglicht es, Accessibility nachträglich auf benutzerdefinierte Widgets zu übertragen – aber die erste Regel lautet: nicht verwenden, wenn natives HTML die Aufgabe übernehmen kann. Schlechtes ARIA ist schlimmer als keines – eine falsche role führt assistive Technologien aktiv in die Irre. Reservieren Sie es für wirklich benutzerdefinierte Komponenten (Tabs, Comboboxes, eigene Dialoge) und folgen Sie den etablierten Patterns, anstatt zu improvisieren.

Accessibility in den Workflow integrieren

Accessibility scheitert, wenn sie ein Pre-Launch-Audit ist statt eine Gewohnheit. Günstige Wege, um sie dauerhaft zu sichern:

1. Einen automatisierten Linter (axe, eslint-plugin-jsx-a11y) in CI einbinden, um offensichtliche Regressionen abzufangen
2. Neue Features vor dem Merge einmal durchtabben
3. Gelegentlich mit einem echten Screenreader testen (VoiceOver, NVDA)

Automatisierte Tools finden vielleicht die Hälfte der Probleme – daher sind die manuellen Prüfungen entscheidend. Aber diese Baseline aus semantischem HTML, Tastaturzugang, Kontrast und ehrlichem ARIA erfüllt den Großteil der Anforderungen und kostet kaum zusätzliche Zeit, wenn sie von Anfang an eingebaut wird.

Wenn Sie ein bestehendes Produkt gegen WCAG prüfen lassen oder Accessibility von Beginn an in ein neues Projekt integrieren möchten, sprechen Sie uns an.