Barrierefreiheit für Entwickler: Inklusiven Code schreiben
Entwickler sind die Architekten der Barrierefreiheit auf der Implementierungsebene. Während Designer die visuellen und interaktiven Grundlagen legen, ist es letztendlich der Code, der bestimmt, ob eine Website mit Tastaturnavigation funktioniert, korrekt mit Screenreadern kommuniziert und die Barrierefreiheit über Browser und Geräte hinweg aufrechterhält.
Die gute Nachricht ist, dass die meisten Best Practices für Barrierefreiheit mit den allgemeinen Best Practices für sauberen, semantischen und standardkonformen Code übereinstimmen. Barrierefreien Code zu schreiben bedeutet nicht, Komplexität hinzuzufügen — es bedeutet, Code von Anfang an korrekt zu schreiben.
Semantisches HTML zuerst
Das Wirkungsvollste, was Sie für die Barrierefreiheit tun können, ist die korrekte Verwendung semantischer HTML-Elemente. HTML5 bietet ein reichhaltiges Vokabular von Elementen mit inhärenter Bedeutung und Barrierefreiheitsfunktionen. Ein <button>-Element ist automatisch fokussierbar, per Tastatur aktivierbar und wird von Screenreadern als Schaltfläche angekündigt. Ein <div> mit einem onclick-Handler hat ohne erheblichen zusätzlichen Aufwand keine dieser Funktionen.
Verwenden Sie <nav> für Navigationsbereiche, <main> für den Hauptinhalt, <header> und <footer> für ihre jeweiligen Bereiche, <section> und <article> für Inhaltsbereiche, <h1> bis <h6> für Überschriften in korrekter hierarchischer Reihenfolge, <ul> und <ol> für Listen, <table> mit <th> für tabellarische Daten, <label> mit for-Attributen für Formularsteuerelemente und native <button>- und <a>-Elemente für interaktive Steuerelemente.
Diese Elemente erstellen einen Accessibility Tree, den assistive Technologien verwenden, um Ihre Inhalte den Nutzern zu präsentieren. Wenn Sie sie korrekt verwenden, wird ein Großteil der Barrierefreiheit automatisch gewährleistet.
Überschriftenstruktur
Überschriften bilden die strukturelle Gliederung Ihrer Seite. Screenreader-Nutzer navigieren häufig über Überschriften, um die Inhaltsorganisation zu verstehen und bestimmte Abschnitte zu finden. Jede Seite sollte genau ein <h1> haben, und Überschriften sollten einer logischen Hierarchie folgen, ohne Ebenen zu überspringen — ein <h3> sollte nicht auf ein <h1> folgen, ohne dass dazwischen ein <h2> steht.
Verwenden Sie niemals Überschriftenelemente für visuelle Gestaltung. Wenn Sie großen fetten Text benötigen, der keine Überschrift ist, verwenden Sie CSS auf einem anderen Element. Umgekehrt: Wenn Inhalt als Überschrift fungiert, kennzeichnen Sie ihn als solche, unabhängig von seiner visuellen Darstellung.
Tastaturzugänglichkeit
Alle Funktionen müssen allein über eine Tastaturschnittstelle bedienbar sein. Das bedeutet, dass jedes interaktive Element — Links, Schaltflächen, Formularsteuerelemente, Menüs, Modale, Schieberegler, Tabs — über die Tab-Taste (oder Shift+Tab für die umgekehrte Richtung) erreichbar, mit Enter oder Leertaste aktivierbar und, wo angemessen, verlassbar sein muss.
Erstellen Sie niemals Tastaturfallen, bei denen Nutzer in ein Element tabben können, aber nicht wieder heraus. Modale Dialoge sollten den Fokus innerhalb des Dialogs halten, solange er geöffnet ist, und den Fokus beim Schließen an das auslösende Element zurückgeben, aber das Drücken von Escape sollte den Dialog immer schließen.
Stellen Sie sicher, dass die Fokusreihenfolge einer logischen Sequenz folgt, die dem visuellen Layout entspricht. Die DOM-Reihenfolge sollte generell der visuellen Darstellung entsprechen. Vermeiden Sie positive tabindex-Werte, die die natürliche Fokusreihenfolge überschreiben und Verwirrung stiften. Verwenden Sie tabindex="0", um nicht-interaktive Elemente bei Bedarf fokussierbar zu machen, und tabindex="-1" für Elemente, die nur programmatisch fokussierbar sein sollen.
Seitensprache
Legen Sie die Standardsprache jeder Seite mit dem lang-Attribut auf dem <html>-Element fest. Dies teilt Screenreadern mit, welche Ausspracheregeln zu verwenden sind. Wenn sich die Sprache innerhalb des Inhalts ändert — zum Beispiel eine französische Phrase auf einer deutschen Seite — kennzeichnen Sie die Änderung mit einem lang-Attribut auf dem umschließenden Element.
Formular-Barrierefreiheit
Formulare sind der Ort, an dem Nutzer Eingaben machen, und sie sind eine häufige Quelle für Barrierefreiheitsmängel. Jedes Formularsteuerelement muss ein programmatisch verknüpftes Label haben, typischerweise über das <label>-Element mit einem for-Attribut, das mit der id des Steuerelements übereinstimmt. Gruppieren Sie zusammengehörige Steuerelemente mit <fieldset> und <legend>.
Wenn Eingabefehler erkannt werden, identifizieren Sie das fehlerhafte Feld und beschreiben Sie den Fehler im Text. Geben Sie nach Möglichkeit Korrekturvorschläge. Für Felder, die bestimmte Formate akzeptieren, geben Sie klare Anweisungen zum erwarteten Format. Verwenden Sie das autocomplete-Attribut, um die Browser-Autovervollständigung für gängige Felder wie Name, E-Mail, Adresse und Telefonnummer zu aktivieren.
Statusmeldungen, die keinen Fokus erhalten — wie „Artikel zum Warenkorb hinzugefügt" oder „3 Ergebnisse gefunden" — müssen Screenreader-Nutzern über ARIA-Live-Regionen oder Status-Rollen angekündigt werden.
Alternativtext
Jedes nicht-dekorative Bild muss einen aussagekräftigen Alternativtext haben, der seinen Inhalt oder seine Funktion beschreibt. Für informative Bilder beschreiben Sie, was das Bild vermittelt. Für funktionale Bilder (wie ein Logo, das zur Startseite verlinkt) beschreiben Sie die Funktion. Für dekorative Bilder, die keine Informationen hinzufügen, verwenden Sie ein leeres alt-Attribut (alt=""), damit Screenreader sie vollständig überspringen.
Komplexe Bilder wie Diagramme, Grafiken oder Schaubilder benötigen möglicherweise längere Beschreibungen, die über eine Bildunterschrift, angrenzenden Text oder eine verlinkte ausführliche Beschreibung bereitgestellt werden.
WAI-ARIA
Die Spezifikation für Accessible Rich Internet Applications bietet zusätzliche Semantik für Situationen, in denen natives HTML nicht ausreicht. ARIA ermöglicht es, Rollen, Zustände und Eigenschaften an assistive Technologien für benutzerdefinierte Widgets und dynamische Inhalte zu kommunizieren.
ARIA sollte jedoch mit Bedacht eingesetzt werden. Die erste Regel von ARIA lautet: Wenn Sie ein natives HTML-Element verwenden können, das die benötigte Semantik und das benötigte Verhalten hat, tun Sie das. ARIA fügt keine Funktionalität hinzu — es fügt nur Semantik hinzu. Ein <div role="button"> benötigt weiterhin JavaScript für die Tastaturbehandlung, während ein natives <button> dies automatisch übernimmt.
Verwenden Sie ARIA-Landmark-Rollen (oder ihre HTML5-Entsprechungen), um Seitenbereiche zu definieren. Verwenden Sie aria-label und aria-labelledby, um barrierefreie Namen bereitzustellen, wenn sichtbarer Text nicht ausreicht. Verwenden Sie aria-expanded, aria-selected, aria-checked und andere Zustandsattribute, um den aktuellen Zustand interaktiver Widgets zu kommunizieren. Verwenden Sie aria-live-Regionen, um dynamische Inhaltsaktualisierungen anzukündigen.
Responsives Design und Umbruch
Inhalte müssen bei einer Breite von 320 CSS-Pixeln ohne Informationsverlust und ohne horizontales Scrollen darstellbar sein. Dies stellt sicher, dass Nutzer, die auf einem Standard-Desktop-Display auf 400 % zoomen, weiterhin auf alle Inhalte zugreifen können. Gestalten Sie Ihre Layouts so, dass Inhalte bei schmalen Breiten in eine einzige Spalte umgebrochen werden, anstatt ein Scrollen in zwei Dimensionen zu erfordern.
Skip-Links
Stellen Sie einen Mechanismus bereit, mit dem Tastaturnutzer wiederholt auftretende Inhaltsblöcke wie Navigationsmenüs überspringen und direkt zum Hauptinhalt springen können. Die häufigste Implementierung ist ein „Zum Hauptinhalt springen"-Link, der das erste fokussierbare Element auf der Seite ist und beim Fokussieren sichtbar wird.
Test-Checkliste für Entwickler
Überprüfen Sie vor der Bereitstellung jeder Funktion: Alle Funktionen sind allein mit der Tastatur bedienbar; die Fokusreihenfolge ist logisch; der Fokus ist auf allen interaktiven Elementen sichtbar; alle Bilder haben geeigneten Alt-Text; alle Formularsteuerelemente haben Labels; die Seitensprache ist festgelegt; die Überschriftenhierarchie ist korrekt; ARIA wird korrekt und nur bei Bedarf verwendet; Inhalte brechen bei 320px Breite um; und dynamische Inhaltsaktualisierungen werden für Screenreader angekündigt.
In diesem Abschnitt
Ist Ihre Website barrierefrei?
Scannen Sie Ihre Website kostenlos und erhalten Sie Ihren WCAG-Score in wenigen Minuten.
Ihre Website kostenlos scannen