Barrierefreie Website: Rechtlicher Rahmen und WCAG-Checkliste

Wer heute eine Website betreibt, erreicht Menschen mit sehr unterschiedlichen Voraussetzungen. In Deutschland leben rund 13 Millionen Menschen mit einer Beeinträchtigung. Viele von ihnen sind auf assistive Technologien angewiesen, um digitale Inhalte zu nutzen.

Hinzu kommen temporäre Einschränkungen wie ein gebrochener Arm oder eine Augenoperation sowie situative Faktoren wie grelles Sonnenlicht auf dem Smartphone-Display. Barrierefreiheit betrifft damit weit mehr Menschen als häufig angenommen und verbessert gleichzeitig die Nutzbarkeit einer Website für alle.

Seit dem 28. Juni 2025 ist digitale Barrierefreiheit für viele Unternehmen gesetzlich verpflichtend. Wer das ignoriert, schließt nicht nur einen relevanten Teil der Nutzer aus, sondern bewegt sich auch außerhalb eines klar definierten rechtlichen Rahmens.

Was digitale Barrierefreiheit wirklich bedeutet

Digitale Barrierefreiheit bedeutet, dass jeder Mensch Inhalte nutzen kann, unabhängig davon, ob er gut sieht, eine Maus bedienen kann oder Informationen schnell erfasst.

In der Praxis zeigt sich Barrierefreiheit nicht in einer einzelnen Maßnahme, sondern im Zusammenspiel mehrerer Ebenen: Inhalte müssen visuell unabhängig funktionieren, die Bedienung muss ohne bestimmte Geräte möglich sein, der technische Code muss maschinell interpretierbar sein, und die Kommunikation muss verständlich aufgebaut sein. Wird eine dieser Ebenen vernachlässigt, entstehen sofort Nutzungshürden.

Visuelle Unabhängigkeit

Inhalte dürfen nicht ausschließlich über visuelle Reize vermittelt werden. Das betrifft vor allem Bilder, Farben und Videos. Bilder benötigen Alternativtexte, Videos Untertitel, und Farbe darf nie alleinige Informationsträgerin sein. Ein klassisches Beispiel ist eine Fehlermeldung, die nur farblich markiert ist, aber keinen erklärenden Text enthält.

Geräteunabhängige Bedienbarkeit

Nicht alle Nutzer verwenden eine Maus. Viele arbeiten ausschließlich mit Tastatur, Sprachsteuerung oder speziellen Eingabegeräten. Eine barrierefreie Website muss deshalb vollständig ohne Maus bedienbar sein. Navigation, Formulare und interaktive Elemente müssen zuverlässig erreichbar bleiben.

Technische Struktur als Grundlage

Assistive Technologien interpretieren nicht das Design, sondern den Code. Sauberes HTML ist daher keine optionale Optimierung, sondern Grundvoraussetzung.

Verständlichkeit und kognitive Zugänglichkeit

Barrierefreiheit umfasst auch die inhaltliche Ebene. Klare Sprache, logische Struktur und nachvollziehbare Abläufe sind entscheidend. Unklare Fehlermeldungen oder komplex formulierte Inhalte stellen ebenso Barrieren dar wie technische Probleme.

Welche Technologien Nutzer einsetzen

Das Spektrum an assistiven Technologien ist breiter als viele vermuten. Je nach Art der Einschränkung greifen Nutzer auf sehr unterschiedliche Werkzeuge zurück.

Diese Technologien machen deutlich: Barrierefreiheit ist keine rein visuelle Disziplin, sondern eine Frage der technischen Zugänglichkeit. Eine Website kann ansprechend gestaltet sein und für Nutzer assistiver Technologien dennoch vollständig unbrauchbar bleiben, wenn die HTML-Struktur nicht stimmt.

Rechtlicher Rahmen: Was gilt für wen und seit wann?

Die rechtliche Situation hat sich in den letzten Jahren deutlich verändert. Während Barrierefreiheit lange primär den öffentlichen Sektor betraf, wurde der Geltungsbereich erheblich erweitert.

Öffentliche Stellen: BITV 2.0 und BGG

Für Behörden und öffentliche Einrichtungen gilt das Behindertengleichstellungsgesetz (BGG). Es definiert den Grundsatz, dass Menschen mit Behinderungen bei der Nutzung öffentlicher Angebote nicht benachteiligt werden dürfen.

Die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) konkretisiert diese Vorgaben technisch. Sie orientiert sich an der europäischen Norm EN 301 549 und damit indirekt an den WCAG. Seit 2018 gelten diese Anforderungen für Websites, seit 2020 auch für mobile Anwendungen. Zusätzlich ist eine Erklärung zur Barrierefreiheit verpflichtend.

Privatwirtschaft: Das BFSG seit dem 28. Juni 2025

Mit dem Barrierefreiheitsstärkungsgesetz (BFSG) wurde der Anwendungsbereich deutlich erweitert. Seit dem 28. Juni 2025 gelten Anforderungen auch für viele private Unternehmen, die digitale Produkte oder Dienstleistungen für Verbraucher anbieten. Betroffen sind insbesondere:

• Online-Shops und E-Commerce-Websites
• Buchungs- und Reservierungssysteme
• Kundenportale und Self-Service-Bereiche
• Banking- und Finanzdienstleistungen
• Telekommunikationsdienste
• Streaming-Plattformen und digitale Medienangebote

Kleinstunternehmen mit weniger als 10 Mitarbeitern und einem Jahresumsatz unter 2 Millionen Euro sind in vielen Fällen ausgenommen. Für bestehende Produkte gelten teilweise Übergangsregelungen.

Regelwerke im Überblick

WCAG: Der technische Standard hinter allen Anforderungen

Die Web Content Accessibility Guidelines (WCAG) bilden die Grundlage für nahezu alle Anforderungen an barrierefreie Websites. Sie übersetzen abstrakte Ziele in konkrete, überprüfbare Kriterien und werden vom W3C als weltweit anerkannter Standard herausgegeben.

Versionen im Kontext

WCAG 2.0 aus dem Jahr 2008 war die erste weit verbreitete Version. Einige ältere nationale Regelungen beziehen sich noch auf sie.

WCAG 2.1 von 2018 erweitert den Standard um Kriterien für mobile Geräte, Menschen mit kognitiven Einschränkungen und Nutzer mit eingeschränktem Sehvermögen. Sie ist aktuell die rechtlich relevante Grundlage für viele Vorgaben.

WCAG 2.2 aus dem Jahr 2023 ergänzt weitere Kriterien, unter anderem zur Fokus-Sichtbarkeit und zu Alternativen für Drag-and-Drop-Interaktionen. Sie repräsentiert den aktuellen Stand der Technik und sollte bei Neuumsetzungen berücksichtigt werden.

Konformitätsstufen

Die drei Stufen definieren den Grad der Barrierefreiheit.

Level AA gilt in der Praxis als maßgeblich. Level AAA ist für bestimmte Bereiche sinnvoll, aber nicht für alle Inhaltstypen vollständig umsetzbar.

Die vier Grundprinzipien

Alle WCAG-Kriterien lassen sich auf vier Prinzipien zurückführen, die im englischen Original unter dem Akronym POUR zusammengefasst werden.

WCAG-Checkliste für WCAG 2.1 Level AA

Die folgende Checkliste bündelt zentrale Anforderungen. Sie ersetzt kein vollständiges Audit, bietet aber einen strukturierten Einstieg in die Prüfung.

Wahrnehmbar

Textalternativen

• Alle informativen Bilder tragen aussagekräftige Alternativtexte über das alt-Attribut
• Dekorative Bilder erhalten ein leeres alt=““ und werden von Screenreadern ignoriert
• Komplexe Grafiken wie Diagramme oder Infografiken werden im Text oder als Langbeschreibung erläutert
• Icons mit Funktion haben einen zugänglichen Namen

Zeitbasierte Medien

• Videos haben synchronisierte, vollständige Untertitel
• Audioinhalte werden durch Transkripte ergänzt
• Videos mit wesentlichen visuellen Informationen enthalten eine Audiodeskription

Anpassbarkeit

• Informationen werden nicht ausschließlich über Form, Farbe, Größe oder Position vermittelt
• Die Lesereihenfolge im Code entspricht der visuellen Reihenfolge

Unterscheidbarkeit

• Normaler Text erreicht ein Kontrastverhältnis von mindestens 4,5:1
• Großer Text ab 18pt oder 14pt fett erreicht mindestens 3:1
• Bedienelemente und Grafiken mit Informationswert erreichen mindestens 3:1
• Der Inhalt bleibt bei 200 Prozent Zoom ohne Verlust nutzbar
• Die Seite erfordert kein horizontales Scrollen bei 320 Pixeln Breite
• Zeilen-, Buchstaben- und Wortabstände lassen sich anpassen, ohne dass Inhalte verloren gehen

Bedienbar

Tastaturbedienbarkeit

• Alle Funktionen sind per Tastatur erreichbar
• Es gibt keine Tastaturfallen, aus denen Nutzer nicht entkommen können
• Tastaturkürzel aus einzelnen Buchstaben lassen sich deaktivieren oder anpassen

Ausreichend Zeit

• Zeitlimits können abgeschaltet, angepasst oder verlängert werden
• Bewegte oder automatisch aktualisierende Inhalte lassen sich pausieren oder stoppen

Anfälle und physische Reaktionen

• Kein Element blinkt häufiger als dreimal pro Sekunde

Navigierbarkeit

• Ein Sprunglink ermöglicht das Überspringen wiederholter Navigationselemente
• Alle Seiten tragen aussagekräftige <title>-Elemente
• Die Tab-Reihenfolge ist logisch und entspricht der visuellen Struktur
• Der Tastaturfokus ist jederzeit sichtbar
• Links sind aus ihrem Linktext heraus verständlich, auch ohne Kontext
• Die Website bietet mehrere Navigationswege, etwa Suche und Sitemap

Eingabemodalitäten

• Drag-and-Drop-Funktionen haben eine Tastaturalternative
• Bewegungsbasierte Eingaben lassen sich alternativ bedienen
• Klickbare Elemente sind mindestens 24 mal 24 Pixel groß

Verständlich

Lesbarkeit

• Die Sprache der Seite ist im HTML über das lang-Attribut definiert
• Sprachwechsel im Text sind ausgezeichnet
• Abkürzungen werden beim ersten Auftreten erklärt oder ausgeschrieben

Vorhersehbarkeit

• Beim Fokussieren oder Ändern von Formularfeldern entstehen keine unerwarteten Kontextwechsel
• Navigation und Bezeichnungen sind konsistent über die gesamte Website
• Neue Tabs, Popups oder andere unerwartete Aktionen werden vorab angekündigt

Eingabehilfe

• Formulare haben eindeutige Labels, die korrekt mit dem Eingabefeld verknüpft sind
• Pflichtfelder sind klar gekennzeichnet, nicht nur durch Farbe
• Fehlermeldungen benennen das Problem konkret und erklären, wie es sich beheben lässt
• Eingabefelder unterstützen Autovervollständigung über das autocomplete-Attribut
• Bei wichtigen Aktionen wie Bestellungen gibt es eine Möglichkeit zur Überprüfung oder Korrektur

Robust

Kompatibilität

• Das HTML ist valide: keine doppelten IDs, korrekte Verschachtelung, vollständige Tags
• Semantische HTML-Elemente wie <nav>, <main>, <header> und <footer> werden korrekt eingesetzt
• Überschriften sind hierarchisch aufgebaut, ohne Sprünge von H1 zu H3
• ARIA-Attribute kommen nur dort zum Einsatz, wo natives HTML nicht ausreicht
• Interaktive Elemente tragen zugängliche Namen, die Screenreader auslesen können
• Statusmeldungen werden programmatisch kommuniziert, etwa über aria-live

Technische Anforderungen im Detail

Struktur und semantisches HTML

Viele Barrieren entstehen nicht durch fehlende Funktionen, sondern durch fehlerhafte Struktur. Besonders häufig sind Probleme bei Überschriften, Navigation und Tabellen.

Semantische Elemente wie <main>, <nav> oder <header> schaffen Orientierung für Screenreader. Fehlen sie, müssen Nutzer Inhalte linear erfassen, statt gezielt zu Navigation, Hauptinhalt oder ergänzenden Bereichen springen zu können.

Die Überschriftenstruktur bildet die Grundlage für Navigation und Inhaltsverständnis. Eine H3 direkt nach einer H1 zu setzen, weil sie optisch besser passt, ist ein häufiger Fehler. Für assistive Technologien zählt die logische Dokumentstruktur, nicht die visuelle Darstellung.

Tabellen brauchen klare Spalten- und Zeilenköpfe über <th>-Elemente mit scope-Attribut. Nur so kann ein Screenreader die Zugehörigkeit von Zelle und Überschrift korrekt kommunizieren. Tabellen sollten ausschließlich für tabellarische Daten verwendet werden, nicht für Layoutzwecke.

Farbkontrast

Kontrastprobleme gehören zu den häufigsten und gleichzeitig am einfachsten lösbaren Barrieren. Sie betreffen nicht nur Menschen mit Sehbehinderung, sondern auch Nutzer in alltäglichen Situationen, etwa bei starkem Licht oder auf kleinen Displays.

Besonders problematisch sind Designs mit sehr hellen Grautönen auf weißem Hintergrund. Sie wirken zeitgemäß, sind für viele Nutzer aber schwer lesbar. Zur Prüfung eignen sich der WebAIM Contrast Checker, der Colour Contrast Analyser oder die Entwicklerwerkzeuge moderner Browser.

Formulare

Formulare sind zentrale Interaktionspunkte. Fehler führen direkt zu Abbrüchen, weil Nutzer Bestellungen, Buchungen oder Kontaktanfragen nicht abschließen können.

Labels müssen eindeutig zugeordnet sein. Platzhaltertexte sind kein Ersatz, weil sie beim Tippen verschwinden und von assistiven Technologien nicht immer zuverlässig verarbeitet werden.

Fehlermeldungen müssen konkret sein und Lösungswege aufzeigen. Die Meldung „Ungültige Eingabe“ ist zu unspezifisch. Besser ist: „Bitte geben Sie eine gültige E-Mail-Adresse ein, zum Beispiel name@domain.de.“

Pflichtfelder müssen so gekennzeichnet sein, dass die Information auch ohne Farbe erkennbar bleibt. Zusätzlich sollte das HTML-Attribut required gesetzt werden, damit assistive Technologien den Status korrekt vermitteln können.

Multimedia

Audioinhalte und Videos brauchen zusätzliche Ebenen der Zugänglichkeit. Automatisch erzeugte Untertitel reichen häufig nicht aus, weil sie oft Fehler enthalten und Fachbegriffe nur unzuverlässig erkennen.

Bei erklärenden Videos ist eine Audiodeskription relevant, wenn wichtige visuelle Informationen nicht über den Ton vermittelt werden. Das betrifft Gestik, Mimik, Bildschirmtexte und visuelle Handlungsabläufe.

Auch der Medienplayer selbst muss zugänglich sein. Abspielen, Pausieren, Lautstärke, Vollbild und Untertitel müssen per Tastatur bedienbar sein. Viele eingebettete Player, auch von etablierten Anbietern, erfüllen diese Anforderungen nicht.

Testen: Warum automatisierte Prüfung nicht ausreicht

Automatisierte Tests sind ein sinnvoller Einstieg, decken aber nur etwa 30 bis 40 Prozent aller Barrieren ab. Sie erkennen technische Fehler wie nicht vorhandene Alternativtexte, Kontrastprobleme oder fehlerhafte Formularzuordnungen zuverlässig. Was sie nicht beurteilen können: ob ein Alternativtext inhaltlich sinnvoll ist, ob die Tab-Reihenfolge logisch wirkt oder ob ein Formular im echten Nutzungskontext verständlich funktioniert.

Deshalb sollte die Prüfung mehrere Ebenen umfassen. Tools wie axe DevTools, WAVE oder Lighthouse decken technische Basisfehler auf und lassen sich gut in Entwicklungsprozesse integrieren. Manuelle Tastaturtests zeigen, ob alle Funktionen erreichbar sind, ob der Fokus sichtbar bleibt und ob es Tastaturfallen gibt. Screenreader-Tests, bei denen zentrale Seiten und Prozesse ohne Blick auf den Bildschirm durchlaufen werden, fördern oft Probleme zutage, die kein automatisiertes Tool erkennt.

Für eine belastbare Einschätzung der realen Nutzbarkeit sind schließlich Tests mit Menschen unverzichtbar, die assistive Technologien im Alltag einsetzen. Organisationen wie die Deutsche Blindenstudienanstalt oder spezialisierte Agenturen bieten entsprechende Testpanels an.

Barrierefreiheit und Suchmaschinenoptimierung

Barrierefreiheit und Suchmaschinenoptimierung verfolgen ähnliche Ziele. Beide benötigen strukturierte, verständliche und technisch saubere Inhalte. Suchmaschinen-Crawler und Screenreader lösen ein ähnliches Problem: Sie interpretieren Inhalte ohne visuelle Gestaltung.

Eine klare Überschriften-Hierarchie hilft Crawlern bei der Themenstruktur und Screenreader-Nutzern bei der Navigation. Alternativtexte machen Bilder für Suchmaschinen auswertbar und für Nutzer mit Sehbehinderung zugänglich. Semantisches HTML erleichtert die Indexierung und verbessert die maschinelle Verarbeitung. Verständliche Linktexte helfen Suchmaschinen bei der Einordnung von Seiten und Nutzern beim Verstehen von Verlinkungen. Wer seine Website barrierefrei gestaltet, verbessert damit gleichzeitig ihre technische Qualität aus Sicht der Suchmaschinen.

Umsetzung in der Praxis

Barrierefreiheit ist kein einmaliges Projekt. Sie entwickelt sich kontinuierlich weiter und muss bei neuen Inhalten, Funktionen und Designs mitgedacht werden.

Am Anfang steht die Analyse. Ein automatisierter Scan der wichtigsten Seiten liefert einen ersten Überblick. Manuelle Tests der kritischsten Prozesse ergänzen das Bild und decken Probleme auf, die Tools nicht erkennen.

Darauf folgt die Priorisierung. Nicht alle Barrieren sind gleich kritisch. Entscheidend ist, wie schwer eine Barriere wiegt und wie viele Nutzer sie betrifft. Navigation, Formulare und Kaufprozesse haben in der Regel höhere Priorität als Randseiten.

In der Umsetzung lassen sich einige Maßnahmen schnell realisieren und erzielen große Wirkung: Alternativtexte ergänzen, Farbkontraste korrigieren, Formular-Labels korrekt verknüpfen, das lang-Attribut setzen und Sprunglinks einbauen. Strukturelle Änderungen wie eine korrigierte Überschriftenhierarchie oder eine verbesserte Tastaturnavigation erfordern meist mehr Aufwand, sind aber zentral für echte Zugänglichkeit.

Öffentliche Stellen sind zur Veröffentlichung einer Erklärung zur Barrierefreiheit verpflichtet. Für private Unternehmen kann eine solche Erklärung ebenfalls Transparenz schaffen, indem sie den Stand der Umsetzung und bekannte Einschränkungen dokumentiert.

FAQ