Barrierefreies Webdesign: Grundlagen, die jede Seite erfüllen sollte

Was barrierefreies Webdesign bedeutet

Barrierefreies Webdesign verfolgt das Ziel, Websites unabhängig von körperlichen, sensorischen oder kognitiven Einschränkungen nutzbar zu machen. Eine barrierearme Seite berücksichtigt unter anderem Menschen mit eingeschränktem Sehvermögen, Hörbehinderungen, motorischen Einschränkungen, Lernschwierigkeiten oder vorübergehenden Beeinträchtigungen. Auch Situationen wie starke Sonneneinstrahlung, eine laute Umgebung, eine langsame Internetverbindung oder die Nutzung eines Smartphones mit einer Hand spielen eine Rolle.

Barrierefreiheit ist dabei keine einzelne Funktion, die nachträglich eingebaut wird. Sie betrifft die gesamte Benutzeroberfläche: Inhalte, Navigation, Farben, Formulare, Bilder, Videos, technische Struktur und Fehlermeldungen. Eine Website kann optisch modern wirken und trotzdem wichtige Zugänge versperren, etwa wenn der Tastaturfokus nicht sichtbar ist oder ein Formular nur durch Farbe verständliche Hinweise liefert.

Als zentrale fachliche Orientierung dienen die Web Content Accessibility Guidelines, kurz WCAG, des World Wide Web Consortiums. Sie ordnen Anforderungen in vier Grundprinzipien ein: wahrnehmbar, bedienbar, verständlich und robust. Diese Prinzipien helfen dabei, Barrierefreiheit nicht als Sammlung isolierter Detailregeln zu betrachten, sondern als Qualitätsmerkmal der gesamten Website.

Die vier WCAG-Prinzipien als Arbeitsgrundlage

Die WCAG strukturieren barrierefreie Webinhalte nach vier Fragen. Kann ein Mensch die Information wahrnehmen? Kann er die Funktionen bedienen? Versteht er Inhalt und Bedienung? Funktioniert die Seite mit unterschiedlichen Browsern, assistiven Technologien und Eingabemethoden?

• Wahrnehmbar: Informationen müssen beispielsweise über Textalternativen, ausreichende Kontraste und Untertitel zugänglich sein.
• Bedienbar: Navigation, Formulare und interaktive Elemente müssen auch ohne Maus und ohne zeitkritische Bedienung funktionieren.
• Verständlich: Sprache, Aufbau, Beschriftungen und Fehlermeldungen sollten nachvollziehbar und vorhersehbar sein.
• Robust: Der technische Code muss so strukturiert sein, dass Browser und assistive Technologien die Bedeutung von Elementen erkennen können.

Die WCAG unterscheiden Erfolgskriterien in den Konformitätsstufen A, AA und AAA. Für die praktische Planung bildet die Stufe AA häufig einen sinnvollen Referenzrahmen. Welche rechtlichen Pflichten gelten, hängt jedoch vom Angebot, vom Sitz des Anbieters und vom anwendbaren Recht ab. Technische Konformität ersetzt deshalb keine rechtliche Prüfung.

Semantisches HTML bildet das Fundament

Semantisches HTML beschreibt die Funktion eines Elements, nicht nur sein Aussehen. Eine Überschrift sollte als Überschrift ausgezeichnet werden, eine Liste als Liste und eine Navigation als Navigationsbereich. Dadurch können Browser und Screenreader die Struktur auswerten und Nutzern passende Sprungmöglichkeiten anbieten.

Die Überschriftenhierarchie sollte logisch aufgebaut sein. Nach der Hauptüberschrift folgen Bereichsüberschriften, darunter bei Bedarf weitere Unterüberschriften. Die Auswahl einer Überschrift darf nicht allein davon abhängen, welche Schriftgröße im Design gewünscht ist. Das Erscheinungsbild lässt sich über CSS steuern, während die HTML-Struktur die inhaltliche Gliederung abbildet.

Für Bedienelemente gelten ähnliche Grundsätze. Ein echter Link eignet sich für den Wechsel zu einer anderen Adresse oder Ansicht. Ein Button löst eine Aktion aus, beispielsweise das Öffnen eines Dialogs oder das Absenden eines Formulars. Ein klickbares div ohne zugänglichen Namen, Tastatursteuerung und Zustandsinformationen erzeugt dagegen unnötige Probleme.

Auch Landmarks wie Kopfbereich, Navigation, Hauptinhalt und Fußbereich können die Orientierung verbessern. Sie sollten sparsam und sinnvoll eingesetzt werden. Eine klare Dokumentstruktur hilft Menschen mit Screenreadern ebenso wie Personen, die Inhalte überfliegen oder mit kleinen Bildschirmen arbeiten.

Tastaturbedienung vollständig sicherstellen

Eine barrierefreie Website muss ohne Maus bedienbar sein. Das betrifft nicht nur die Hauptnavigation, sondern auch Menüs, Suchfelder, Dialogfenster, Schieberegler, Tabs, Cookie-Einstellungen und interaktive Karten. Nutzer müssen mit der Tabulatortaste alle relevanten Elemente erreichen können. Die Reihenfolge sollte der visuellen und inhaltlichen Logik entsprechen.

Der Tastaturfokus muss jederzeit deutlich sichtbar sein. Wird der Standard-Fokus mit CSS entfernt, ohne einen gleichwertigen Ersatz zu definieren, verliert der Nutzer die Orientierung. Ein sichtbarer Rahmen oder eine vergleichbare Hervorhebung sollte sich klar vom Hintergrund abheben.

Bei Dialogfenstern sind mehrere Punkte zu prüfen. Beim Öffnen sollte der Fokus in den Dialog wechseln. Während der Dialog geöffnet ist, darf der Fokus nicht unkontrolliert hinter das Fenster springen. Nach dem Schließen sollte er an die auslösende Stelle zurückkehren. Die Escape-Taste kann das Schließen unterstützen, sofern dies zum Bedienkonzept passt.

Ungewöhnliche Tastenkombinationen, automatische Fokuswechsel und zeitlich begrenzte Aktionen sollten vermieden oder erklärbar gemacht werden. Ein Nutzer darf nicht in einer Komponente feststecken. Jede Funktion, die mit einem Zeiger bedient werden kann, sollte auch über die Tastatur erreichbar sein.

Kontraste, Farben und visuelle Orientierung

Text muss sich ausreichend vom Hintergrund abheben. Für die Bewertung ist nicht der persönliche Eindruck entscheidend, sondern das Kontrastverhältnis nach den WCAG-Kriterien. Die konkreten Mindestwerte hängen unter anderem von Schriftgröße und Schriftstärke ab. Kleine oder dünne Schrift benötigt in der Regel einen stärkeren Kontrast als große, kräftige Schrift.

Farbe darf nie die einzige Informationsträgerin sein. Ein Pflichtfeld sollte nicht nur durch eine rote Umrandung erkennbar sein. Ein Status sollte neben der Farbe auch durch Text, ein Symbol oder eine andere eindeutige Kennzeichnung beschrieben werden. Das hilft Menschen mit Farbsehschwäche und allen Nutzern, die den Bildschirm unter ungünstigen Bedingungen betrachten.

Bei der Gestaltung sollten Textabstände, Zeilenhöhe und Vergrößerung berücksichtigt werden. Inhalte dürfen bei vergrößerter Darstellung nicht abgeschnitten werden oder hinter anderen Elementen verschwinden. Feste Höhen für Textcontainer sind deshalb riskant, insbesondere wenn Nutzer die Schriftgröße anpassen.

Ein praktischer Prüfablauf besteht aus mehreren Schritten:

1. Die Seite in Graustufen betrachten und prüfen, ob Zustände weiterhin unterscheidbar sind.
2. Text und Bedienelemente mit einem Kontrastprüfwerkzeug untersuchen.
3. Die Darstellung bei vergrößerter Schrift und schmaler Bildschirmbreite kontrollieren.
4. Hover-, Fokus-, Aktiv- und Fehlzustände separat testen.

Bilder, Symbole und alternative Texte

Alternative Texte vermitteln den Informationsgehalt eines Bildes, wenn dieses nicht gesehen werden kann. Ein gutes Alt-Attribut benennt daher nicht pauschal den Dateityp, sondern die für den Kontext relevante Aussage. Zeigt ein Bild beispielsweise ein bestimmtes Gerät, kann die Funktion oder Situation wichtiger sein als eine lange Beschreibung sämtlicher sichtbarer Details.

Dekorative Bilder brauchen keinen beschreibenden Alternativtext. Sie sollten für assistive Technologien als dekorativ markiert werden, damit Screenreader keine überflüssigen Dateinamen oder Beschreibungen vorlesen. Ob ein Bild informativ oder dekorativ ist, hängt vom Zusammenhang ab, nicht allein vom Motiv.

Bei verlinkten Bildern muss der alternative Text das Ziel oder die Funktion des Links verständlich machen. Ein Icon für die Suche braucht etwa einen zugänglichen Namen wie „Suche öffnen“, wenn keine sichtbare Beschriftung vorhanden ist. Wird ein Symbol zusammen mit Text verwendet, sollte nicht derselbe Inhalt unnötig doppelt ausgegeben werden.

Komplexe Grafiken, Diagramme und Infografiken benötigen meist mehr als ein kurzes Alt-Attribut. Die wesentlichen Aussagen gehören zusätzlich in den umgebenden Text oder in eine ausführliche Beschreibung. So bleibt die Information auch dann verfügbar, wenn die Grafik nicht wahrgenommen werden kann.

Videos, Audio und bewegte Inhalte zugänglich machen

Videos sollten Untertitel enthalten, wenn gesprochene Inhalte oder relevante Geräusche vorkommen. Automatisch erzeugte Untertitel können eine erste Arbeitsgrundlage sein, müssen aber auf Erkennungsfehler, Fachbegriffe, Namen und Zeichensetzung geprüft werden. Für wichtige audiovisuelle Inhalte kann zusätzlich eine Audiodeskription erforderlich sein, die visuelle Informationen für blinde oder sehbehinderte Menschen beschreibt.

Audiodateien brauchen eine textliche Alternative oder ein Transkript. Das Transkript sollte nicht nur den gesprochenen Text, sondern bei Bedarf auch bedeutende Geräusche und Sprecherwechsel kenntlich machen. Ein automatisch startendes Audioelement kann die Nutzung mit Screenreadern und in öffentlichen Umgebungen erschweren. Bewegte Inhalte sollten pausierbar sein, insbesondere wenn sie Aufmerksamkeit binden oder schnell flackern.

Animationen können bei Menschen mit vestibulären Beschwerden Unwohlsein auslösen. Eine Einstellung zur Reduzierung von Bewegung sollte respektiert werden, wenn das Betriebssystem oder der Browser diese Präferenz übermittelt. Wichtige Informationen dürfen nicht ausschließlich in einer Animation erscheinen.

Formulare verständlich und fehlertolerant gestalten

Formulare gehören zu den häufigsten Barrieren. Jedes Eingabefeld braucht eine dauerhaft erkennbare Beschriftung, die technisch mit dem Feld verbunden ist. Platzhalter ersetzen diese Beschriftung nicht, weil sie nach der Eingabe verschwinden und häufig einen zu geringen Kontrast besitzen.

Pflichtfelder, erlaubte Formate und Einheiten sollten vor der Eingabe verständlich erklärt werden. Bei einem Datumsfeld ist eine konkrete Formatangabe hilfreicher als eine allgemeine Fehlermeldung. Werden mehrere Eingabefelder zu einer Gruppe zusammengefasst, etwa bei einer Lieferadresse oder einer Auswahl mehrerer Optionen, sollte die Gruppierung auch technisch erkennbar sein.

Fehler müssen in Textform benannt werden. Eine rote Umrandung allein liefert keine ausreichende Information. Die Fehlermeldung sollte möglichst nahe am betroffenen Feld erscheinen und den Fehler beschreiben. Noch hilfreicher ist ein konkreter Korrekturhinweis, sofern die Ursache eindeutig erkannt werden kann.

Nach dem Absenden eines Formulars sollte der Nutzer erfahren, ob die Übermittlung erfolgreich war. Bei Fehlern kann eine zusammenfassende Meldung am Anfang des Formulars Orientierung geben. Der Fokus sollte so gesetzt werden, dass Nutzer die Meldung und anschließend die fehlerhaften Felder ohne lange Suche erreichen.

Klare Sprache und vorhersehbare Navigation

Verständlichkeit betrifft Inhalt und Bedienung. Kurze Sätze, aussagekräftige Überschriften und eine nachvollziehbare Reihenfolge erleichtern die Orientierung. Fachbegriffe lassen sich nicht immer vermeiden, sollten aber erklärt werden, wenn sie für die Zielgruppe nicht selbstverständlich sind.

Links sollten ihr Ziel erkennen lassen. Beschriftungen wie „Mehr“ oder „Weiter“ sind problematisch, wenn auf einer Seite mehrere gleichartige Links vorkommen. Eine präzisere Formulierung benennt den Inhalt, etwa „Systemanforderungen anzeigen“ oder „Anleitung zur Datensicherung öffnen“.

Die Navigation sollte auf vergleichbaren Seiten an derselben Stelle und in derselben Reihenfolge erscheinen. Komponenten dürfen nicht unerwartet den Kontext verändern, nur weil ein Feld den Fokus erhält oder eine Auswahl getroffen wurde. Wenn eine Aktion ein neues Fenster öffnet, ein Formular absendet oder Daten verändert, sollte dies vorher erkennbar sein.

Eine Suchfunktion, eine gut strukturierte Hauptnavigation und ein sichtbarer Seitenpfad können die Orientierung verbessern. Bei langen Inhalten sind Sprunglinks nützlich. Diese müssen selbst erreichbar und verständlich beschriftet sein.

Responsive Design und unterschiedliche Eingabemethoden

Barrierefreiheit endet nicht bei der Desktopansicht. Auf kleinen Bildschirmen müssen Inhalte ohne horizontales Scrollen lesbar bleiben, soweit dies für die jeweilige Darstellung möglich ist. Bedienelemente brauchen ausreichend Platz und dürfen nicht so dicht angeordnet sein, dass versehentliche Eingaben wahrscheinlich werden.

Die Bedienung darf nicht von einer einzigen Eingabemethode abhängen. Touch, Tastatur, Maus, Spracheingabe und assistive Technologien können unterschiedliche Anforderungen stellen. Gesten mit mehreren Fingern oder präzises Ziehen sollten eine alternative Bedienmöglichkeit erhalten.

Bei responsiven Menüs ist zu prüfen, ob der Öffnungszustand für Screenreader erkennbar ist. Ein Menüknopf sollte seinen Zustand mitteilen, und die enthaltenen Links müssen in sinnvoller Reihenfolge erreichbar sein. Wird ein Element auf kleinen Bildschirmen ausgeblendet, darf dadurch keine wesentliche Funktion verloren gehen.

Robuster Code und Einsatz von ARIA

Robustheit bedeutet, dass die Bedeutung und der Zustand einer Komponente technisch nachvollziehbar bleiben. Gültiges, gut strukturiertes HTML ist dafür die wichtigste Grundlage. ARIA, die Accessible Rich Internet Applications, kann zusätzliche Informationen bereitstellen, wenn native HTML-Elemente nicht ausreichen.

ARIA sollte jedoch nicht verwendet werden, um schlecht gewählte HTML-Elemente nachträglich zu reparieren. Ein nativer Button bringt wichtige Eigenschaften für Tastatur und assistive Technologien bereits mit. Ein nicht interaktives Element mit einer Button-Rolle benötigt dagegen meist zusätzliche Zustands-, Fokus- und Tastatursteuerung. Das erhöht die Fehlergefahr.

Bei dynamischen Inhalten müssen Statusänderungen zugänglich angekündigt werden, sofern sie für die weitere Bedienung relevant sind. Das kann beispielsweise eine Meldung nach dem Speichern oder eine Aktualisierung der Suchergebnisse betreffen. Gleichzeitig sollten nicht alle visuellen Änderungen automatisch vorgelesen werden, da zu viele Ansagen die Nutzung erschweren.

Technische Prüfungen sollten daher nicht ausschließlich auf einen automatischen Scanner vertrauen. Werkzeuge erkennen bestimmte Muster, aber nicht zuverlässig die Qualität eines Alternativtexts, die Verständlichkeit einer Beschriftung oder die logische Bedienung eines komplexen Dialogs.

Ein praxisnaher Prüfplan für bestehende Websites

Eine systematische Prüfung beginnt mit einer Bestandsaufnahme. Zuerst werden Seitentypen und wiederkehrende Komponenten erfasst: Startseite, Inhaltsseite, Suchansicht, Formulare, Anmeldung, Warenkorb oder vergleichbare zentrale Abläufe. Danach werden die wichtigsten Nutzungssituationen und Zielgruppen beschrieben.

1. Struktur prüfen: Überschriften, Landmarks, Listen, Tabellen und Linkziele im Code untersuchen.
2. Tastaturtest durchführen: Die komplette Seite ohne Maus bedienen und Fokusreihenfolge, sichtbaren Fokus sowie Dialoge dokumentieren.
3. Visuelle Prüfung vornehmen: Kontraste, Schriftvergrößerung, responsive Ansichten und Zustände kontrollieren.
4. Medien und Bilder bewerten: Alternative Texte, Untertitel, Transkripte und Pausenfunktionen prüfen.
5. Formulare testen: Beschriftungen, Pflichtfelder, Fehlermeldungen und Erfolgsmeldungen mit realistischen Eingaben prüfen.
6. Assistive Technologien einbeziehen: Screenreader und gegebenenfalls Vergrößerungssoftware in repräsentativen Abläufen einsetzen.
7. Prioritäten festlegen: Blockierende Barrieren zuerst beheben, danach Komfort- und Detailverbesserungen umsetzen.

Die Ergebnisse sollten mit URL oder Seitentyp, beobachtetem Problem, betroffenen Nutzern, Schweregrad und konkretem Lösungsvorschlag dokumentiert werden. Screenshots können die Kommunikation unterstützen, ersetzen aber keine Beschreibung des zugrunde liegenden Problems.

Automatische Tests und manuelle Kontrolle kombinieren

Automatische Prüfwerkzeuge können fehlende Alternativtexte, bestimmte Kontrastprobleme, unbeschriftete Formularfelder oder fehlerhafte ARIA-Attribute aufdecken. Sie eignen sich besonders für regelmäßige Stichproben und für die Prüfung wiederverwendeter Komponenten. Ein positives Prüfergebnis bedeutet jedoch nicht, dass die Seite insgesamt barrierefrei ist.

Manuelle Tests bleiben unverzichtbar. Dazu gehören die Bedienung per Tastatur, die Prüfung bei hoher Zoomstufe, die Bewertung der Sprache und die Nutzung mit einem Screenreader. Für wichtige Prozesse sollte eine Person den vollständigen Ablauf aus Sicht einer betroffenen Nutzergruppe durchspielen.

Bei Änderungen am Design oder an Komponenten sollte eine Regressionprüfung stattfinden. Ein neues Dialogfenster kann beispielsweise den Fokus verlieren, während die übrige Seite weiterhin fehlerfrei wirkt. Eine Komponentenbibliothek mit dokumentierten Anforderungen hilft, wiederkehrende Fehler zu vermeiden.

Prüfbereich	Typische Frage	Geeignete Kontrolle
Struktur	Sind Überschriften und Bereiche logisch angeordnet?	Codeprüfung und Screenreader-Test
Tastatur	Sind alle Funktionen erreichbar und ist der Fokus sichtbar?	Manuelle Bedienung ohne Maus
Darstellung	Bleiben Inhalte bei Vergrößerung und schmaler Breite nutzbar?	Responsive und visuelle Prüfung
Formulare	Werden Eingaben, Fehler und Ergebnisse verständlich vermittelt?	Test mit absichtlich fehlerhaften Eingaben
Medien	Sind Audio- und Videoinhalte auch ohne vollständige Wahrnehmung verständlich?	Untertitel-, Transkript- und Pausentest

Barrierefreiheit in den Arbeitsprozess integrieren

Barrierefreiheit wird wirtschaftlicher und zuverlässiger umgesetzt, wenn sie nicht erst am Ende eines Projekts geprüft wird. Bereits bei der Anforderungsanalyse sollten Tastaturbedienung, Kontrast, alternative Texte, Fehlermeldungen und responsive Darstellung als Akzeptanzkriterien festgehalten werden.

Im Design sollten Zustände wie Fokus, Fehler, Deaktivierung, Laden und Erfolg sichtbar ausgearbeitet werden. Für jede Komponente ist zu klären, welche Information sichtbar ist und welche davon technisch vermittelt werden muss. Entwickler sollten native HTML-Elemente bevorzugen und wiederverwendbare Muster dokumentieren.

Redaktionelle Prozesse brauchen ebenfalls klare Regeln. Wer Bilder einpflegt, sollte wissen, wann ein Alt-Text erforderlich ist und wann ein Bild dekorativ bleibt. Wer Videos veröffentlicht, benötigt Vorgaben für Untertitel und Transkripte. Neue Inhalte sollten vor der Veröffentlichung inhaltlich und technisch geprüft werden.

Ein kontinuierlicher Verbesserungsprozess kann aus regelmäßigen Stichproben, dokumentierten Korrekturen und erneuten Tests bestehen. Dabei sollte nicht nur die Einhaltung einzelner Kriterien betrachtet werden. Entscheidend ist, ob Menschen zentrale Aufgaben tatsächlich durchführen können, etwa Informationen finden, ein Konto verwalten oder ein Formular absenden.

FAQ: Häufige Fragen zum barrierefreien Webdesign

Ist eine barrierefreie Website nur für Menschen mit Behinderung wichtig?

Nein. Klare Strukturen, gut lesbare Kontraste, Untertitel und verständliche Fehlermeldungen helfen vielen Menschen. Davon profitieren auch Nutzer mit vorübergehenden Einschränkungen, geringer Aufmerksamkeit, schlechten Lichtverhältnissen oder kleinen Bildschirmen.

Reicht ein automatischer Barrierefreiheits-Check aus?

Nein. Automatische Werkzeuge erkennen nur bestimmte technische Muster. Sie bewerten beispielsweise nicht zuverlässig, ob ein Alternativtext den Bildinhalt sinnvoll vermittelt oder ob ein komplexer Ablauf verständlich ist. Manuelle Tastatur-, Zoom- und Screenreader-Tests bleiben erforderlich.

Wann sollte ARIA eingesetzt werden?

ARIA kann bei komplexen, dynamischen Komponenten zusätzliche Rollen, Zustände und Eigenschaften vermitteln. Native HTML-Elemente sind jedoch vorzuziehen, wenn sie die benötigte Funktion bereits abbilden. Falsch eingesetzte ARIA-Attribute können die Zugänglichkeit verschlechtern.

Was ist der wichtigste erste Schritt?

Ein vollständiger Tastaturtest zentraler Nutzerabläufe liefert oft schnell Hinweise auf grundlegende Barrieren. Parallel dazu sollten Überschriftenstruktur, Formularbeschriftungen, Kontraste und alternative Texte geprüft werden. Die Ergebnisse sollten priorisiert und nach der Korrektur erneut getestet werden.