Accessibility (a11y)

Warum Barrierefreiheit wichtig ist

Barrierefreiheit bedeutet, Anwendungen für Menschen zu entwickeln, die assistive Technologien nutzen, die Navigation per Tastatur verwenden, einen höheren Kontrast benötigen oder reduzierte Bewegungen bevorzugen. Etwa jeder sechste Mensch lebt mit einer Behinderung, und fast jeder profitiert irgendwann von Barrierefreiheit – sei es durch einen gebrochenen Arm, einen zu hellen Bildschirm oder einen lärmenden Zug.

Zudem wird sie immer häufiger gesetzlich gefordert. Gesetzgebungen und Beschaffungsrichtlinien in vielen Ländern beziehen sich auf die WCAG, sodass Barrierefreiheit eine professionelle Grundvoraussetzung und kein optionales Extra ist. Das Beruhigende daran ist, dass der Großteil davon erreicht wird, wenn man die Grundlagen konsequent richtig umsetzt.

WCAG und POUR

Die Web Content Accessibility Guidelines definieren den Standard. Ihre vier Grundprinzipien sind:

• Wahrnehmbar (Perceivable) — Inhalte müssen wahrgenommen werden können, zum Beispiel durch Textalternativen für Bilder und ausreichend Kontrast.
• Bedienbar (Operable) — Alles muss per Tastatur steuerbar sein und darf keine präzise Mausführung erfordern.
• Verständlich (Understandable) — Inhalte und Verhalten müssen vorhersehbar und klar sein.
• Robust — Die Anwendung muss mit aktuellen und zukünftigen User Agents sowie assistiven Technologien funktionieren.

Jedes Prinzip verfügt über testbare Erfolgskriterien auf den Stufen A, AA und AAA. Die meisten Teams streben die Stufe AA an.

Semantisches HTML ist das Fundament

Ein Großteil der Barrierefreiheit ergibt sich bereits aus der Verwendung der richtigen Elemente. Native Elemente bringen ihre eigenen Rollen, Zustände und Tastaturverhalten mit.

<!-- semantics.html -->
<header>
  <nav aria-label="Main">
    <a href="/">Home</a>
  </nav>
</header>
<main>
  <h1>Dashboard</h1>
  <button type="button" aria-expanded="false">Filters</button>
</main>

Ein <button> ist fokussierbar, reagiert auf Enter und Leertaste und wird als Button angesagt. Ein <div onclick> ist nichts davon. Aus diesem Grund steht der Semantic HTML Guide vor diesem hier: Semantik ist der effizienteste Weg, um die Barrierefreiheit schnell zu verbessern.

Tastatur-Unterstützung

Jedes interaktive Element muss allein über die Tastatur erreichbar und bedienbar sein.

• Verwende native Controls, da diese standardmäßig fokussierbar sind.
• Halte die Tab-Reihenfolge logisch; sie sollte der visuellen Reihenfolge entsprechen.
• Biete einen Skip-Link an, damit Nutzer sich wiederholende Navigationsmenüs überspringen können.
• Sperre den Fokus niemals in einer Komponente ein, ohne eine Möglichkeit zum Verlassen (Escape) zu bieten.
• Zeige einen deutlichen Fokus-Indikator an und entferne Outlines niemals, ohne sie durch eine sichtbare Alternative zu ersetzen.

<!-- skip.html -->
<a href="#main" class="skip-link">Skip to content</a>
<main id="main" tabindex="-1">...</main>

Fokus-Management

Der Fokus ist quasi der Cursor für Tastaturbenutzer. Verwalte ihn bewusst:

• Wenn sich ein Dialog öffnet, verschiebe den Fokus hinein und halte ihn dort gefangen (Focus Trap).
• Wenn er geschlossen wird, gib den Fokus an das Element zurück, das ihn geöffnet hat.
• Bei einer client-seitigen Navigation verschiebe den Fokus auf den neuen Inhalt.
• Nach Validierungsfehlern setze den Fokus auf das erste ungültige Feld.

Moderne Dialoge können das <dialog>-Element mit showModal() verwenden, welches einen Großteil dieser Aufgaben automatisch übernimmt.

Textalternativen

Bilder benötigen Textalternativen, die ihren Zweck im jeweiligen Kontext vermitteln.

• Informative Bilder erhalten eine Beschreibung dessen, was sie aussagen.
• Dekorative Bilder erhalten alt="", damit sie übersprungen werden.
• Funktionale Bilder, wie etwa ein Icon innerhalb eines Links, beschreiben die entsprechende Aktion.
• Komplexe Bilder benötigen eine ausführlichere Beschreibung in der Nähe.

Das gleiche Prinzip gilt für Medien: Stellen Sie Bildunterschriften für Videos, Transkripte für Audio und Labels für jedes Formularsteuerelement bereit.

ARIA mit Bedacht einsetzen

ARIA fügt Semantik hinzu, die HTML allein nicht ausdrücken kann, lässt sich aber leicht falsch verwenden. Die erste Regel von ARIA lautet: Verwenden Sie ARIA nicht, wenn ein natives Element die Aufgabe bereits erledigt. Ein <div role="button"> ist in fast jeder Hinsicht schlechter als ein <button>.

Wenn Sie es dennoch benötigen:

• aria-label benennt ein Element, das keinen sichtbaren Text hat.
• aria-labelledby referenziert sichtbaren Text, der das Element benennt.
• aria-describedby verknüpft ein Steuerelement mit einem Hinweis oder einer Fehlermeldung.
• aria-expanded, aria-controls und aria-live beschreiben Zustände und dynamische Aktualisierungen.

Testen Sie ARIA mit einem echten Screenreader; ein fehlerhaftes ARIA ist oft schlimmer als gar keines.

Farbe und Kontrast

Text benötigt einen ausreichenden Kontrast zum Hintergrund:

• 4,5:1 für normalen Text, 3:1 für großen Text gemäß AA-Standard.
• 3:1 für Icons, Rahmen und Fokus-Indikatoren.
• Verwenden Sie niemals Farbe als einziges Mittel, um eine Bedeutung zu vermitteln; ergänzen Sie diese durch Text, Icons oder Muster.

Überprüfen Sie den Kontrast mit einem Tool und testen Sie Ihr Design in Graustufen, um eine rein farbbasierte Kommunikation zu identifizieren.

Bewegung und Präferenzen

Berücksichtigen Sie die Präferenzen der Nutzer.

/* motion.css */
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Große Parallax-Effekte und Scroll-Animationen sind die häufigsten Fehlerquellen. Vermeiden Sie zudem das automatische Abspielen von Medien mit Ton und stellen Sie Steuerelemente für alles bereit, was sich bewegt.

Testing

Automatisierte Tools finden vielleicht ein Drittel der Probleme. Kombinieren Sie diese mit manuellen Tests:

1. Führen Sie axe oder Lighthouse aus, um häufige Verstöße zu finden.
2. Navigieren Sie ausschließlich mit der Tastatur und prüfen Sie dabei den Fokus und die Reihenfolge.
3. Zoomen Sie auf 200 % und prüfen Sie, ob etwas kaputtgeht oder überlappt.
4. Probieren Sie einen Screenreader aus: VoiceOver, NVDA oder Narrator.
5. Prüfen Sie den Kontrast und ob Informationen ausschließlich über Farben vermittelt werden.
6. Testen Sie Formulare mit Fehlermeldungen und dynamischen Inhalten.

Der Testing Library Guide zeigt, wie zugängliche Queries die Barrierefreiheit zu einem festen Bestandteil Ihrer Test-Suite machen.

Best Practices

• Beginnen Sie mit semantischem HTML, bevor Sie ARIA hinzufügen.
• Stellen Sie sicher, dass alles per Tastatur bedienbar ist und ein sichtbarer Fokus vorhanden ist.
• Bieten Sie Textalternativen für alle bedeutsamen Medien an.
• Erfüllen Sie den AA-Kontraststandard und verlassen Sie sich niemals allein auf Farben.
• Verwalten Sie den Fokus bei Dialogen, der Navigation und bei Fehlern.
• Berücksichtigen Sie reduced motion und vermeiden Sie automatisch startende Medien.
• Testen Sie mit automatisierten Tools und echter assistiver Technologie.

Häufige Fehler

• Verwendung von divs als Buttons oder Links.
• Entfernen von Focus-Outlines aus ästhetischen Gründen.
• Fehlender oder wenig hilfreicher Alt-Text.
• Fehlerhafte Implementierung von ARIA, wodurch native Semantiken zerstört werden.
• Text mit geringem Kontrast und Zustände, die nur über Farben kommuniziert werden.
• Vernachlässigung von Tastaturbenutzern bei benutzerdefinierten Widgets.

Wie geht es weiter?

Barrierefreiheit ist eine kontinuierliche Praxis und keine einfache Checkliste. Bauen Sie auf Semantic HTML auf, machen Sie Formulare mit Forms & Validation nutzbar und integrieren Sie diese Aspekte in Ihre Tests mit Testing Library. Suchen Sie sich anschließend eine Seite aus, navigieren Sie diese ausschließlich mit der Tastatur und beheben Sie die Fehler, die Ihnen dabei auffallen.