Barrierefreie Websites erstellen

Barrierefreiheit im Web ist nicht optional – sie ist eine grundlegende Voraussetzung für inklusive digitale Erlebnisse. Weltweit leben über eine Milliarde Menschen mit einer Form von Behinderung, und barrierefreies Design kommt allen zugute, nicht nur Menschen mit dauerhaften Einschränkungen.

Untertitel helfen jemandem, der im Zug ein Video ansieht. Starker Kontrast hilft jemandem, der im Sonnenlicht auf sein Smartphone schaut. Tastaturunterstützung hilft Power-Usern ebenso wie der Person, deren Handgelenk diesen Monat in Gips liegt.

Dieser Leitfaden behandelt den Standard, die Muster, die die meisten realen Probleme lösen, und eine Testroutine, die sich in die normale Entwicklung einfügt.

WCAG verstehen

Die Web Content Accessibility Guidelines (WCAG) bieten einen Rahmen, um Webinhalte wahrnehmbar, bedienbar, verständlich und robust zu gestalten. Diese vier Prinzipien – oft mit POUR abgekürzt – bilden das Fundament aller Barrierefreiheitsstandards.

Zu den wichtigsten Erfolgskriterien gehören Textalternativen für Nicht-Text-Inhalte, ausreichende Farbkontraste, die vollständige Bedienbarkeit per Tastatur und mehrere Wege, um durch Inhalte zu navigieren.

Stufen und Versionen

Jedem Erfolgskriterium ist eine Stufe zugeordnet: A, AA oder AAA. Stufe AA ist für die meisten Organisationen das praktische Ziel und die Stufe, auf die die meisten Beschaffungsvorgaben und Barrierefreiheitsrichtlinien verweisen. AAA ist nicht für alle Inhalte erreichbar; betrachten Sie es daher als ambitioniertes Ziel für einzelne Seiten.

WCAG 2.2 wurde im Oktober 2023 zur W3C-Empfehlung. Die Version baut auf 2.1 auf, statt sie zu ersetzen, sodass Arbeit, die Sie für die ältere Version geleistet haben, weiterhin gilt. Ein Kriterium, 4.1.1 Syntaxanalyse, wurde als überholt gestrichen. Wenn Sie ein neues Projekt beginnen, orientieren Sie sich an WCAG 2.2 AA.

Was WCAG 2.2 hinzugefügt hat

Die neuen Kriterien sollten Sie beim Namen kennen, denn sie decken Probleme auf, die ältere Checklisten übersehen:

• 2.4.11 Fokus nicht verdeckt (Minimum), AA – ein fokussiertes Element darf nicht vollständig durch vom Autor erstellte Inhalte wie einen Sticky Header oder ein Cookie-Banner verdeckt werden.
• 2.5.7 Ziehbewegungen, AA – alles, was per Ziehen erledigt wird, etwa das Umsortieren einer Liste oder das Bewegen eines Schiebereglers, braucht eine Alternative mit einem einzelnen Zeiger.
• 2.5.8 Zielgröße (Minimum), AA – Zeigerziele sollten mindestens 24 × 24 CSS-Pixel groß sein oder genügend Abstand zueinander haben, mit einigen wenigen aufgeführten Ausnahmen.
• 3.2.6 Konsistente Hilfe, A – Hilfemechanismen, die sich über mehrere Seiten wiederholen, erscheinen in derselben relativen Reihenfolge.
• 3.3.7 Redundante Eingabe, A – zwingen Sie Menschen nicht, Informationen erneut einzugeben, die sie im selben Prozess bereits angegeben haben.
• 3.3.8 Barrierefreie Authentifizierung (Minimum), AA – die Anmeldung darf nicht von einem kognitiven Funktionstest wie dem Merken oder Abtippen eines Codes abhängen, es sei denn, es gibt eine Alternative oder Unterstützung (etwa indem Einfügen und Passwortmanager erlaubt sind).

Die übrigen drei neuen Kriterien (2.4.12, 2.4.13 und 3.3.9) gehören zur Stufe AAA.

Gängige Barrierefreiheitsmuster

Beginnen Sie mit semantischem HTML. Eine korrekte Überschriftenhierarchie, Landmark-Elemente und Formularbeschriftungen decken bereits einen erheblichen Teil der Anforderungen ab. ARIA-Attribute sollten die native HTML-Semantik ergänzen, nicht ersetzen.

Native Elemente bevorzugen

Ein button-Element ist fokussierbar, wird mit Enter und Leertaste ausgelöst, stellt die Rolle „button“ bereit und funktioniert in Formularen. Ein div mit Klick-Handler kann nichts davon, bis Sie es von Hand nachbauen, und den meisten Eigenbauten fehlt am Ende etwas.

<!-- Vermeiden: braucht role, tabindex und Tasten-Handler, um annähernd gleichzuziehen -->
<div class="btn" onclick="save()">Save</div>

<!-- Bevorzugen: Tastatur, Fokus und Semantik inklusive -->
<button type="button" onclick="save()">Save</button>

Dasselbe gilt für Links (a mit href für Navigation, button für Aktionen), details und summary für ausklappbare Inhalte sowie dialog für Modals. Wenn kein natives Element passt, folgen Sie dem WAI-ARIA Authoring Practices Guide, statt ein eigenes Tastaturmodell zu erfinden.

Landmarks und Überschriften

Screenreader-Nutzer navigieren häufig über Landmarks und Überschriften, statt von oben nach unten zu lesen. Geben Sie jeder Seite genau ein main, umschließen Sie die Website-Navigation mit nav und verwenden Sie header und footer für seitenweite Kopf- und Fußbereiche. Wenn Sie mehr als ein nav haben, geben Sie jedem ein aria-label, damit sie sich unterscheiden lassen.

Überschriften sollten die Struktur des Inhalts beschreiben, nicht seine optische Größe. Springen Sie nicht von h2 zu h4, weil der kleinere Stil besser aussah; ändern Sie stattdessen den Stil.

Formulare

Jedes Eingabefeld braucht eine programmatisch verknüpfte Beschriftung. Platzhaltertext ist keine Beschriftung: Er verschwindet bei der Eingabe und erfüllt oft die Kontrastanforderungen nicht. Gruppieren Sie zusammengehörige Bedienelemente mit fieldset und legend und verknüpfen Sie Hinweise und Fehlermeldungen mit ihren Feldern:

<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email"
       aria-describedby="email-hint email-error" aria-invalid="true">
<p id="email-hint">We will only use this to send your receipt.</p>
<p id="email-error">Enter an email address in the format name@example.com.</p>

Fehlermeldungen sollten sagen, was schiefgelaufen ist und wie es sich beheben lässt. Verschieben Sie beim Absenden den Fokus auf eine Fehlerzusammenfassung oder das erste ungültige Feld, damit Tastatur- und Screenreader-Nutzer nicht raten müssen. Auch das Attribut autocomplete ist wichtig: Es erfüllt 1.3.5 Zweck der Eingabe bestimmen und erspart allen Tipparbeit.

Fokusmanagement

Fokusmanagement ist für Single-Page-Anwendungen entscheidend. Wenn sich Inhalte dynamisch ändern, sorgen Sie dafür, dass sich der Fokus vorhersehbar bewegt, damit Screenreader-Nutzer verstehen, was sich geändert hat. Verwenden Sie aria-live-Regionen, um dynamische Aktualisierungen anzukündigen.

Einige Regeln decken die meisten Fälle ab:

• Verschieben Sie nach einem clientseitigen Routenwechsel den Fokus auf die Hauptüberschrift oder den Hauptbereich der neuen Seite und aktualisieren Sie den Dokumenttitel.
• Wenn sich ein Modal öffnet, verschieben Sie den Fokus hinein und halten ihn dort; schließt es sich, geben Sie den Fokus an das Bedienelement zurück, das es geöffnet hat. Das native dialog-Element, geöffnet mit showModal(), übernimmt vieles davon für Sie.
• Entfernen Sie den Fokusindikator niemals, ohne ihn zu ersetzen. Verwenden Sie :focus-visible, um Tastaturnutzern einen deutlichen Ring anzuzeigen, ohne ihn bei jedem Mausklick einzublenden.
• Live-Regionen müssen im DOM existieren, bevor sich ihr Inhalt ändert, sonst kündigen viele Screenreader die Aktualisierung nicht an. Verwenden Sie aria-live="polite" für Statusmeldungen und reservieren Sie assertive für wirklich dringende Meldungen.

Farbe und Kontrast

Normaler Text braucht ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund, großer Text (etwa 18 pt oder 14 pt fett) 3:1 (1.4.3). Bedienelemente und bedeutungstragende Grafiken wie Eingabefeldrahmen, Fokusringe und Diagrammlinien brauchen 3:1 gegenüber angrenzenden Farben (1.4.11). Prüfen Sie sowohl das helle als auch das dunkle Theme; eine Palette, die in einem besteht, fällt im anderen oft durch.

Farbe darf nie das einzige Mittel sein, um Informationen zu vermitteln (1.4.1). Ein roter Rahmen um ein ungültiges Feld sollte von einem Symbol oder Text begleitet werden; eine Diagrammreihe sollte sich neben dem Farbton auch durch Beschriftung, Muster oder Position unterscheiden lassen.

Bewegung und Zoom

Respektieren Sie die Bewegungseinstellung der Nutzer. Großflächige Parallax-Effekte und automatisch abspielende Animationen können Menschen mit vestibulären Störungen echte Beschwerden bereiten.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Inhalte sollten sich außerdem bei einer Breite von 320 CSS-Pixeln ohne horizontales Scrollen neu anordnen (1.4.10) – so sieht ein 1280 Pixel breites Fenster bei 400 % Zoom aus. Verwenden Sie relative Einheiten für Schrift, vermeiden Sie feste Höhen bei Textcontainern und deaktivieren Sie niemals das Pinch-Zoom im Viewport-Meta-Tag.

Ihre Arbeit testen

Automatisierte Werkzeuge wie axe-core und Lighthouse erkennen nur einen Teil der Barrierefreiheitsprobleme. Sie sind hervorragend bei objektiven Prüfungen wie fehlenden Beschriftungen, ungültigem ARIA und Kontrastfehlern, können Ihnen aber nicht sagen, ob ein Alternativtext aussagekräftig ist, ob die Fokusreihenfolge sinnvoll ist oder ob eine Interaktion verständlich ist. Manuelle Tests mit Tastaturnavigation und Screenreadern (VoiceOver, NVDA, JAWS) sind unverzichtbar, um den Rest zu finden. Beziehen Sie Menschen mit Behinderungen in Ihre Nutzerforschung ein, um das genaueste Feedback zu erhalten.

Eine Routine, die in die Entwicklung passt

1. Linting und Unit-Tests. Setzen Sie einen Barrierefreiheits-Linter für Ihr Framework ein und ergänzen Sie Komponenten- und End-to-End-Tests um automatisierte axe-Prüfungen, damit Regressionen den Build fehlschlagen lassen.
2. Tastaturdurchgang. Ziehen Sie die Maus ab. Gehen Sie per Tab durch die Seite: Können Sie jedes Bedienelement erreichen und bedienen, ist der Fokusindikator immer sichtbar und ist die Reihenfolge logisch?
3. Zoom und Reflow. Zoomen Sie auf 200 % und 400 %. Nichts sollte sich überlappen, abgeschnitten werden oder Scrollen in zwei Richtungen erfordern.
4. Stichprobe mit dem Screenreader. Wählen Sie den kritischen Pfad – Registrierung, Checkout, das Haupt-Dashboard – und durchlaufen Sie ihn mit einem Screenreader. Achten Sie auf unbeschriftete Buttons, nicht angekündigte Fehler und eine verwirrende Lesereihenfolge.
5. Einstellungen prüfen. Schalten Sie reduzierte Bewegung, erzwungene Farben (Windows-Kontrastmodus) und den Dark Mode ein und vergewissern Sie sich, dass nichts Wichtiges verschwindet.

Damit es dauerhaft hält

Barrierefreiheit scheitert meist schleichend: Eine Funktion, die Monate später hinzukommt, zerstört unbemerkt eine Fokusfalle. Einige Gewohnheiten verhindern das:

• Schreiben Sie Akzeptanzkriterien zur Barrierefreiheit direkt in die Tickets, nicht in ein separates Audit-Backlog.
• Verankern Sie die Muster in gemeinsam genutzten Komponenten, damit Produktteams standardmäßig korrektes Verhalten erhalten.
• Veröffentlichen Sie eine Erklärung zur Barrierefreiheit, die angibt, welchem Standard Sie entsprechen, welche bekannten Probleme bestehen und wie Menschen Probleme melden können.

Barrierefreie Websites zu erstellen ist eine fortlaufende Verpflichtung, doch die heute verfügbaren Werkzeuge und Muster machen sie für jedes Entwicklungsteam erreichbar. Beginnen Sie mit semantischem HTML, testen Sie bei jedem Release mit der Tastatur und behandeln Sie jeden Barrierefreiheitsfehler mit derselben Ernsthaftigkeit wie jeden anderen Fehler, der Nutzer aussperrt.