Magazin Barrierefreie Website 2026: Was jetzt Pflicht ist – und wie Sie Ihren Status schnell selbst prüfen
Seit dem 28. Juni 2025 ist das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft – 2026 ist nun das erste Jahr, in dem Marktüberwachungsbehörden aktiv prüfen. Was lange als freiwilliges Qualitätsmerkmal galt, ist damit gesetzliche Pflicht. Unternehmen, die das Thema aufgeschoben haben, geraten nun unter Zugzwang.
Wir zeigen Ihnen, wo die größten Hebel für eine barrierefreie Website liegen, wie Sie Ihren Stand mit einem einfachen Selbstcheck in 30 Minuten einschätzen und warum diese Maßnahmen Ihr SEO und Ihre Sichtbarkeit in KI-Systemen stärken.
Das Wichtigste in Kürze
- Für viele Unternehmen sind barrierefreie Websites seit Juni 2025 gesetzliche Pflicht.
- Die entscheidenden Barrierefreiheitsprobleme liegen oft in den Basics: fehlende Struktur und Semantik, schwache Kontraste, fehlende Alt-Texte und mangelhafte Tastaturbedienbarkeit.
- Semantisches HTML und klare Strukturen helfen nicht nur Screenreadern, sondern stärken auch Crawlbarkeit und Sichtbarkeit in KI-Systemen.
- Verlassen Sie sich nicht auf fehleranfällige automatische Overlays: Ein einfacher 5-Punkte-Selbstcheck zeigt Ihnen, wo Sie stehen.
Barrierefreiheit 2026 – kein Nice-to-have mehr, sondern Standard
Das BFSG setzt den European Accessibility Act (EAA) in deutsches Recht um. Es gilt für Unternehmen, die Produkte oder Dienstleistungen für Verbraucher:innen anbieten – etwa über Online-Shops, Ticket- und Buchungsportale oder serviceorientierte Unternehmenswebsites. Kleinstunternehmen mit weniger als zehn Beschäftigten und einem Jahresumsatz unter zwei Millionen Euro können für bestimmte Dienstleistungen ausgenommen werden.
Der maßgebliche technische Standard dahinter ist WCAG 2.2 Level AA – die aktuelle Version der Web Content Accessibility Guidelines des W3C mit konkreten Anforderungen an barrierefreie Websites und Apps. Daneben ist die europäische Norm EN 301 549 relevant, die zusätzlich Apps, Software und digitale Hardware umfasst.
Barrierefreiheit ist dabei mehr als Compliance. Sie ist ein Qualitätsfaktor für UX, Performance, Conversion Rate und Markenwahrnehmung. Wer Barrierefreiheit ernst nimmt, baut Websites, die für mehr Menschen nutzbar sind, bessere Nutzungsdaten liefern und langfristig rechtliche Risiken reduzieren.
Wo die größten Hebel liegen – die fünf Basics der Barrierefreiheit
Die meisten Barrieren entstehen nicht in exotischen Spezialfällen, sondern in fünf grundlegenden Bereichen einer Website. Wer diese fünf Basics sauber umsetzt, erfüllt einen Großteil der WCAG-Anforderungen und löst die meisten Probleme.
-
01
Struktur & semantisches HTML
Semantisches HTML ist die Basis einer barrierefreien Website. Das bedeutet: native Elemente wie <main>, <nav>, <button> oder <header> statt generischer <div>-Konstruktionen ohne Bedeutung. Eine saubere Heading-Hierarchie – eine <h1> pro Seite, logische <h2>- und <h3>-Ebenen – gibt Screenreadern und Suchmaschinen-Crawlern die nötige Orientierung. Ein häufiger Fehler sind klickbare <div>-Elemente ohne Tastaturunterstützung oder ARIA-Rolle; native Elemente bringen diese Logik bereits mit.
-
02
Farbkontrast & Lesbarkeit
Der Mindestkontrast für normalen Text liegt nach WCAG 2.2 Level AA bei 4,5:1 gegenüber dem Hintergrund. Das lässt sich mit kostenlosen Tools in wenigen Sekunden prüfen – kritisch wird es oft bei Sekundärfarben, deaktivierten Buttons oder Beschriftungen auf farbigen Flächen. Inhalte dürfen nicht ausschließlich über Farbe kommuniziert werden: Wer Fehler nur durch rote Schrift kennzeichnet, schließt farbenfehlsichtige Nutzer:innen aus.
-
03
Textalternativen / Alt-Texte
Alt-Texte für Bilder sind nicht optional: Sie beschreiben, was das Bild zeigt und warum es auf der Seite steht. Keyword-Stuffing ist hier fehl am Platz. Rein dekorative Bilder erhalten ein leeres alt=""-Attribut – das ist WCAG-konform und sorgt dafür, dass Screenreader sie überspringen.
-
04
Tastaturbedienung & Tastaturnavigation
Eine vollständig per Tastatur bedienbare Website ist sowohl WCAG-Anforderung als auch ein klarer UX-Gewinn. Tab-Navigation, Enter zum Aktivieren und Escape zum Schließen sollten konsistent funktionieren. WCAG 2.2 verschärft die Anforderungen an den Fokus-Indikator: Er muss bestimmte Mindestgrößen und Kontrastverhältnisse erfüllen (2.4.11 „Focus Appearance“). Der Fokus darf beim Öffnen von Modals oder dynamischen Inhalten nie „verloren gehen“, sondern muss aktiv verwaltet werden. Skip-Links wie „Zum Inhalt springen“ am Seitenanfang lassen Tastaturnutzer:innen direkt zum Hauptinhalt springen und sind eine einfache, wirkungsvolle Maßnahme.
-
05
Verständliche Sprache & barrierefreie Formulare
Jedes Formularfeld braucht ein eigenes <label>-Element, das über for-/id-Attribute mit dem Eingabefeld verknüpft ist; Placeholder-Text allein reicht nicht, weil er beim Tippen verschwindet. Fehlermeldungen sollten klar und handlungsorientiert formuliert sein – etwa „Bitte geben Sie eine gültige E-Mail-Adresse ein“ statt „Ungültige Eingabe“. WCAG 2.2 ergänzt hier unter anderem: Login-Prozesse dürfen keine kognitiven Tests ohne Alternative erfordern (3.3.8 „Accessible Authentication“), und Hilfe-Elemente wie Chat, FAQ oder Kontakt müssen auf allen Seiten konsistent platziert sein (3.2.6 „Consistent Help“).
Die technische Perspektive – Barrierefreiheit in der Frontend-Architektur
Barrierefreiheit ist keine nachträgliche Schicht, die man auf eine fertige Website aufträgt. Sie betrifft DOM-Struktur, Event-Handling und Fokus-Management – und damit die grundlegende Architektur des Frontends.
Typische Fehler, die wir in der Praxis sehen:
- Fokus-Management nach dynamischen Inhalten fehlt: Öffnet sich ein Modal, wandert der Fokus nicht hinein – und beim Schließen nicht zurück zum auslösenden Element. Tastaturnutzer:innen verlieren die Orientierung, obwohl die Oberfläche „funktioniert“.
- Custom-Komponenten ohne Tastaturunterstützung: Selbst gebaute Dropdowns, Tabs oder Slider lassen sich oft nur mit der Maus bedienen. Ohne vollständiges Keyboard-Handling werden sie zur Barriere – Standard-HTML-Elemente sind hier meist die robustere Lösung.
- Falsche ARIA-Nutzung: ARIA-Attribute sollen fehlende Semantik ergänzen, nicht ersetzen. Wer ein <div> mit role="button" versieht, aber kein korrektes Keyboard-Handling implementiert, verschiebt das Problem und riskiert zusätzliche Fehler im Zusammenspiel mit Screenreadern.
- Zu schwacher Kontrast bei Sekundärfarben: Im Designsystem ist der Grundkontrast oft sauber gelöst, in der Umsetzung werden aber Buttons, Badges oder disabled States nicht mitgeprüft. Gerade hier entstehen häufig Verstöße gegen die WCAG-Kontrastanforderungen.
Accessibility-Overlays – Browser-Plugins oder externe Skripte, die Barrierefreiheit per JavaScript nachrüsten sollen – lösen diese Architekturprobleme nicht. Sie legen sich über den bestehenden Code, ohne DOM-Struktur, Semantik, Fokus-Logik oder Kontraste wirklich zu korrigieren. Häufig stören sie sogar Screenreader, unterbrechen die Tastaturnavigation und erzeugen eine trügerische Sicherheit im Hinblick auf Compliance. Echte Barrierefreiheit entsteht im Code – durch semantisches HTML, sauberes Fokus-Management und korrekt eingesetzte ARIA-Attribute.
Fünf Tests, die Sie jetzt ohne Spezial-Tools durchführen können
Bevor Sie ein Audit beauftragen oder Spezial-Tools einsetzen, können Sie mit fünf einfachen Tests den Status Ihrer Website grob einschätzen.
Test 1 – Tastatur-Navigation
Öffnen Sie Ihre Website und navigieren Sie ausschließlich mit der Tab-Taste durch die Seite. Prüfen Sie, ob Sie alle interaktiven Elemente – Links, Buttons, Formulare und Menüs – erreichen und aktivieren können und ob jederzeit sichtbar bleibt, welches Element fokussiert ist.
Warnsignal: Der Fokusrahmen verschwindet, springt unlogisch oder bestimmte Elemente sind per Tastatur gar nicht erreichbar.
Test 2 – Überschriften-Struktur
Prüfen Sie, ob Ihre Seite genau eine H1 enthält und ob H2- und H3-Überschriften in einer logischen Reihenfolge folgen. Eine saubere Überschriften-Hierarchie hilft Screenreadern und Suchmaschinen, Inhalte korrekt einzuordnen. Das Browser-Plugin HeadingsMap zeigt Ihnen die komplette Heading-Struktur einer Seite auf einen Blick.
Warnsignal: Überschriften werden nur für die Optik eingesetzt oder die Hierarchie ist gebrochen – etwa wenn direkt auf eine H1 eine H3 folgt.
Test 3 – Formulare & Labels
Schauen Sie sich alle Formulare auf Ihrer Website an. Hat jedes Eingabefeld ein sichtbares Label, das auch beim Ausfüllen erhalten bleibt, und sind Fehlermeldungen nach dem Absenden konkret und verständlich formuliert?
Warnsignal: Ein Feld ist nur über Placeholder-Text beschriftet oder Fehlermeldungen sagen nicht klar, was korrigiert werden soll – das ist ein Barrierefreiheitsproblem und erschwert oft auch die Conversion.
Test 4 – Farbkontrast & Lesbarkeit
Reduzieren Sie Ihre Bildschirmhelligkeit oder betrachten Sie Ihre Website bei hellem Umgebungslicht. Prüfen Sie, ob Fließtext gut lesbar bleibt und ob Buttons auch ohne ihre Farbe als klickbar erkennbar sind – etwa durch Form, Rahmen oder Beschriftung.
Warnsignal: Text auf farbigem Hintergrund wirkt blass oder interaktive Elemente unterscheiden sich ausschließlich durch Farbe. Das weist oft auf unzureichende Kontraste hin.
Test 5 – Screenreader-Kurztest
Aktivieren Sie NVDA als kostenlosen Screenreader für Windows oder VoiceOver auf dem Mac. Lassen Sie sich die Startseite vorlesen und navigieren Sie über Überschriften, Links und Formulare durch die Seite. Achten Sie darauf, ob die Struktur verständlich vorgelesen wird und ob Bilder sinnvoll beschrieben sind.
Dieser Test wirkt aufwendiger, liefert aber oft schon in wenigen Minuten klare Hinweise darauf, ob Struktur, Alternativtexte und Fokusführung Ihrer Website funktionieren.
Tools als Ergänzung – nicht als Ersatz
Automatische Test-Tools sind hilfreich, stoßen aber schnell an Grenzen: Sie decken in der Praxis oft nur etwa 30–40% der tatsächlichen Accessibility-Probleme ab. Alles, was Verständlichkeit von Inhalten, Bedienlogik oder das Screenreader-Erlebnis betrifft, muss manuell geprüft werden.
Für einen ersten Check eignen sich zum Beispiel:
- Lighthouse (in den Chrome DevTools unter „Accessibility”): Gibt ohne zusätzliche Installation einen Score und konkrete Hinweise zu gefundenen Problemen.
- WAVE: Visualisiert Fehler, Warnungen und Strukturelemente direkt auf der Seite und liefert einen schnellen Überblick über typische Barrieren.
Für tiefergehende Prüfungen – etwa im Rahmen eines Accessibility-Audits oder für kontinuierliches Monitoring – kommen spezialisierte Tools wie axes4, Silktide oder Siteimprove zum Einsatz. Unser intern entwickeltes Tool „a11y“ ergänzt diese Prüfungen um projektspezifische Regelsets und priorisierte Findings.
Was Ihr Ergebnis bedeutet
Wenn Sie in den fünf Tests mehr als zwei oder drei Warnsignale finden, besteht konkreter Handlungsbedarf. Das ist eher die Regel als die Ausnahme – die meisten Websites haben strukturelle Lücken in mehreren der fünf Bereiche.
Drei realistische Szenarien:
- Viele Warnsignale: Hoher Handlungsbedarf. Starten Sie mit den Basics – insbesondere Struktur und Fokus-Management haben den größten Impact.
- Unsicherheit bei einzelnen Tests: Es gibt wahrscheinlich Lücken, die ohne Code-Einblick schwer einzuschätzen sind, etwa bei Tastaturnavigation oder Screenreader-Verhalten. Ein Audit schafft hier Klarheit.
- Basics nicht erfüllt: Keine echte Barrierefreiheit, auch wenn bisher keine Beschwerden eingegangen sind – fehlende Rückmeldungen bedeuten keinen rechtssicheren Zustand.
Perfektion ist nicht das Ziel – Struktur schon. Mit den fünf Basics legen Sie die Grundlage, auf der sich alle weiteren Maßnahmen zur barrierefreien Website aufbauen lassen.
Barrierefreiheit und SEO – warum barrierefreie Websites besser gefunden werden
Barrierefreiheit und Suchmaschinenoptimierung verfolgen dieselben technischen Ziele: klare Struktur, verständliche Inhalte und sauberer HTML-Code. Das ist kein Zufall – Suchmaschinen-Crawler und Screenreader stehen vor ähnlichen Herausforderungen: Sie können Inhalte nicht sehen, sondern müssen sie aus Struktur und Code erschließen.
Einige typische Maßnahmen der Barrierefreiheit zahlen dabei direkt auf SEO ein:
| Barrierefreiheits-Maßnahme | SEO-Wirkung |
| Semantisches HTML | Bessere Crawlbarkeit, klare Dokumentstruktur |
| Heading-Hierarchie | Themenrelevanz für Suchmaschinen erkennbar |
| Alt-Texte für Bilder | Bildverständnis, bessere Auffindbarkeit in Google Image Search |
| Explizite Labels & Fließtexte | Klare Kontextsignale für Rankings |
| Video-Untertitel & Transkripte | Zusätzlicher indexierbarer Content |
Indirekte Effekte kommen über bessere UX: Wer eine Seite gut bedienen kann, bleibt länger. Geringere Absprungraten und längere Verweildauer sind Signale, die in die Qualitätsbewertung und damit indirekt ins Ranking einfließen. Barrierefreie Strukturen führen außerdem häufig zu schlankeren, schnelleren Seiten – mit positivem Einfluss auf die Core Web Vitals.
GEO – warum barrierefreie Seiten von KI-Systemen besser verstanden werden
KI-Systeme wie ChatGPT, Perplexity oder Google AI Overviews lesen Webseiten ähnlich wie Screenreader: Sie orientieren sich an klaren Strukturen, semantischen Relationen und verständlichen Inhalten – nicht an der visuellen Gestaltung.
Was das konkret bedeutet:
- Klare H1–H3-Struktur: Eine saubere Überschriften-Hierarchie macht Themen und Subtopics für KI-Systeme als separate Einheiten erkennbar – und damit grundsätzlich zitierfähig.
- Semantische Beziehungen: Korrekt verschachtelter Content mit semantischen HTML-Elementen hilft KI, Hauptthema, Unterpunkte und Detailargumente auseinanderzuhalten.
- Beschreibende Alt-Texte und Fließtexte: Alt-Texte und klar formulierte, vollständige Sätze ohne Ellipsen können von KI direkt als Bausteine in Antworten auf Nutzerfragen verwendet werden.
Was für Screenreader verständlich ist, ist auch für Suchmaschinen und KI leichter interpretierbar. Das ist keine Garantie für Top-Rankings, schafft aber eine deutlich bessere Basis und erhöht die Chance, in KI-generierten Antworten und AI Overviews aufzutauchen. Barrierefreiheit und GEO-Optimierung sind daher keine getrennten Aufgaben: Wer semantisch sauber baut, stärkt SEO, Accessibility und GEO gleichzeitig.
Häufige Fragen zu barrierefreien Websites
Gilt das BFSG auch für meine Website?
Ja, wenn Sie online Produkte oder Dienstleistungen für Verbraucher:innen anbieten (z.B. Shop, Buchungsportal, Service-Website). Kleinstunternehmen mit weniger als 10 Mitarbeitenden und bis zu 2 Mio. Euro Umsatz können teilweise ausgenommen sein – im Zweifel rechtlich prüfen lassen.
Was bedeutet WCAG 2.2 Level AA in der Praxis?
WCAG 2.2 Level AA heißt vor allem: ausreichende Kontraste, Tastaturnavigation, sinnvolle Alt-Texte, klare Überschriften-Struktur und verständliche Formulare mit erkennbarem Fokus.
Kann ein Accessibility-Overlay meine Website BFSG-konform machen?
Nein. Overlays beheben keine Code-Probleme und können Screenreader sowie Tastaturnutzung stören. Barrierefreiheit entsteht im HTML, im Fokus-Management und in korrekt eingesetztem ARIA – nicht durch ein zusätzliches Skript.
Wo fange ich an, wenn meine Website nicht barrierefrei ist?
Starten Sie mit den fünf Basics und dem 5‑Punkte-Selbstcheck aus diesem Artikel. Wenn Sie dabei mehrere Warnsignale finden, hilft ein Accessibility-Audit mit priorisierter Maßnahmenliste.
