Barrierefreie Website 2026: BFSG, WCAG und praktische Checkliste für Unternehmen

Eine barrierefreie Website ist 2026 kein Spezialthema mehr für Behörden. Das Barrierefreiheitsstärkungsgesetz, steigende Nutzererwartungen und die wachsende Bedeutung digitaler Selbstbedienung machen Accessibility für viele Unternehmen zu einem praktischen Qualitätskriterium. Wer online verkauft, Termine annimmt, Kundenportale betreibt oder digitale Informationen bereitstellt, sollte prüfen, ob die eigene Website für Menschen mit unterschiedlichen Fähigkeiten wirklich nutzbar ist.

Dieser Artikel ordnet BFSG, WCAG und die wichtigsten Umsetzungsschritte ein. Er ersetzt keine Rechtsberatung, hilft aber bei der technischen und redaktionellen Planung. Für die Vertiefung lohnt sich zusätzlich der Lexikonartikel Was ist das BFSG? und die Leistungsseite Barrierefreiheit.

Barrierefreie Website 2026: Warum das Thema jetzt operativ wird

Das BFSG setzt die europäische Barrierefreiheitsrichtlinie für bestimmte Produkte und Dienstleistungen in deutsches Recht um. Nach Angaben der Bundesfachstelle Barrierefreiheit betrifft das Gesetz unter anderem bestimmte digitale Dienstleistungen. Die praktische Relevanz für Websites entsteht besonders dort, wo Online-Shops, Buchungsstrecken, Bankdienstleistungen, Telekommunikation, E-Books oder digitale Verbraucherprozesse angeboten werden.

Unabhängig von der juristischen Betroffenheit ist Barrierefreiheit auch ein wirtschaftliches Thema. Eine Website, die mit Tastatur bedienbar ist, klare Kontraste nutzt, verständliche Fehlermeldungen zeigt und Inhalte semantisch strukturiert, hilft nicht nur Menschen mit dauerhaften Einschränkungen. Sie hilft auch Nutzern mit temporären Einschränkungen, älteren Besuchern, mobilen Nutzern, Menschen in Stresssituationen und allen, die Informationen schnell erfassen möchten.

Barrierefreiheit ist Website-Qualität unter realen Nutzungsbedingungen. Sie betrifft Design, Code, Content, Formulare, Medien, Dokumente und Prozesse.

Nicht jedes Unternehmen ist automatisch in gleicher Weise vom BFSG betroffen. Trotzdem sollten deutlich mehr Website-Betreiber prüfen, ob digitale Prozesse barrierefrei genug sind. Entscheidend sind unter anderem Branche, Angebot, Zielgruppe, Vertragsabschluss, digitale Dienstleistung und Verbraucherbezug. Wer unsicher ist, sollte die rechtliche Bewertung separat klären und die technische Website-Qualität trotzdem nicht aufschieben.

Website- oder Prozessart	Warum eine Prüfung sinnvoll ist
Online-Shop und Checkout	Kauf, Warenkorb, Zahlung und Bestätigung sind kritische Verbraucherprozesse.
Buchungs- und Terminportale	Nutzer müssen Leistungen selbstständig auswählen, buchen und verwalten können.
Mitglieder-, Kunden- oder Serviceportale	Login, Formulare und Dokumente müssen auch mit Hilfstechnologien nutzbar sein.
Banken, Versicherungen, Telekommunikation	Digitale Dienstleistungen stehen häufig besonders im Fokus.
Unternehmenswebsite mit Lead-Formularen	Auch ohne klare BFSG-Pflicht kann Barrierefreiheit Conversion, Vertrauen und Reichweite verbessern.

Für viele KMU ist der pragmatische Schluss: nicht warten, bis eine Beschwerde oder rechtliche Unsicherheit entsteht, sondern die wichtigsten Nutzerwege prüfen und schrittweise verbessern.

BFSG, WCAG und praktische Verantwortung

Das BFSG formuliert rechtliche Anforderungen für bestimmte Produkte und Dienstleistungen. Die WCAG, also die Web Content Accessibility Guidelines, liefern den weltweit etablierten technischen und konzeptionellen Rahmen für Web-Barrierefreiheit. Die aktuelle W3C-Empfehlung WCAG 2.2 organisiert Anforderungen in Prinzipien, Richtlinien und testbaren Erfolgskriterien mit Konformitätsstufen A, AA und AAA.

Für Unternehmenswebsites ist WCAG 2.2 AA in vielen Projekten der sinnvolle Zielkorridor, auch wenn die genaue rechtliche Bewertung vom konkreten Angebot abhängt. Wichtig ist: WCAG ist keine einzelne Checkliste, die man am Ende abhakt. Es ist ein Qualitätsrahmen für Gestaltung, Entwicklung und Redaktion.

Die vier Grundprinzipien lassen sich gut merken:

Prinzip	Bedeutung für Websites
Wahrnehmbar	Inhalte müssen sichtbar, hörbar oder anderweitig erfassbar sein.
Bedienbar	Navigation, Formulare und Interaktionen müssen ohne Barrieren funktionieren.
Verständlich	Sprache, Struktur, Fehler und Prozesse müssen nachvollziehbar sein.
Robust	Inhalte müssen mit verschiedenen Browsern, Geräten und Hilfstechnologien funktionieren.

Diese Prinzipien zeigen, warum reine Overlay-Lösungen nicht ausreichen. Ein Widget kann Schriftgröße, Kontrast oder Fokusunterstützung verbessern, aber es repariert keine falsche Überschriftenstruktur, keine unbedienbaren Formulare, keine fehlenden Alternativtexte und keine schlecht gebauten Dialoge.

In der Umsetzung hilft es, die WCAG-Prinzipien nicht abstrakt zu lesen, sondern auf reale Seitenelemente zu übertragen. „Wahrnehmbar“ betrifft etwa Kontraste, Alternativtexte, Untertitel und klare Zustände. „Bedienbar“ betrifft Tastaturbedienung, Fokus, Menüs, Slider, Dialoge und Zeitlimits. „Verständlich“ betrifft Sprache, Navigation, Fehlermeldungen und Formularhilfen. „Robust“ betrifft semantisches HTML, ARIA nur dort, wo es gebraucht wird, und Kompatibilität mit Browsern und Screenreadern.

Ein Beispiel: Ein Formularfeld mit grauem Placeholder, ohne sichtbares Label und roter Fehlermarkierung verletzt gleich mehrere Ebenen. Der Text ist möglicherweise schlecht wahrnehmbar, das Feld ist für Screenreader nicht eindeutig benannt, die Fehlermeldung wird nur farblich vermittelt und der Nutzer versteht nicht, wie er den Fehler behebt. Barrierefreiheit ist deshalb selten eine einzelne Korrektur. Sie ist meist das Zusammenspiel aus Gestaltung, Code und Text.

Typische Schwachstellen auf Unternehmenswebsites

In Audits tauchen bestimmte Probleme besonders häufig auf. Viele davon entstehen nicht aus Nachlässigkeit, sondern aus fehlenden Standards im Design- und Entwicklungsprozess.

• Zu geringe Farbkontraste bei Buttons, Labels, Icons oder grauen Texten.
• Fokuszustände sind unsichtbar oder werden durch CSS entfernt.
• Navigation, Slider, Filter oder Akkordeons sind nicht vollständig per Tastatur bedienbar.
• Formulare zeigen Fehlermeldungen nur farblich oder erst nach Browser-Validierung.
• Labels fehlen oder sind nicht korrekt mit Eingabefeldern verbunden.
• Überschriften werden nach optischer Größe statt semantischer Reihenfolge gesetzt.
• Bilder, Icons und Infografiken haben fehlende oder unbrauchbare Alt-Texte.
• Modale Fenster halten Fokus nicht korrekt oder lassen sich nicht mit Escape schließen.
• Videos haben keine Untertitel oder keine sinnvolle Textalternative.
• PDFs sind nicht barrierefrei oder werden als Ersatz für wichtige HTML-Inhalte genutzt.
• Cookie-Banner blockieren Tastaturbedienung oder Screenreader.
• Checkout- und Buchungsprozesse verlieren Kontext bei Fehlern.

Gerade bei Shops, Buchungssystemen und Mitgliederbereichen genügt es nicht, nur die Startseite zu prüfen. Kritisch sind die Interaktionsstrecken: Produktauswahl, Warenkorb, Checkout, Registrierung, Login, Passwort-Reset, Zahlungsfluss und Bestätigung. Für E-Commerce-Projekte ist deshalb auch die Schnittstelle zu WooCommerce und individuellen Checkout-Anpassungen relevant.

Kritische Prozesse: Shop, Buchung, Formular und Login

Viele Barrieren werden erst sichtbar, wenn ein Nutzer einen Prozess abschließen muss. Eine Startseite kann technisch ordentlich sein, während Checkout, Formular oder Login kaum bedienbar sind. Unternehmen sollten deshalb nicht nur Seitentypen prüfen, sondern echte Aufgaben.

Bei Formularen geht es nicht nur um Labels. Nutzer müssen verstehen, welche Angaben erwartet werden, welche Felder Pflicht sind, warum ein Fehler auftritt und wie er behoben wird. Fehlermeldungen sollten direkt beim Feld stehen, programmatisch erkennbar sein und nicht nur durch rote Farbe auffallen. Nach einem Fehler sollten bereits eingegebene Daten erhalten bleiben.

Bei Shops und Buchungen kommen weitere Punkte hinzu: Variantenwahl, Preisänderungen, Warenkorb, Lieferadresse, Zahlungsart, AGB-Hinweise, Gutscheinfelder und Bestätigung müssen mit Tastatur, Screenreader und Zoom funktionieren. Auch Cookie-Banner, Captchas und Zahlungsanbieter können den Prozess unterbrechen. Genau diese Übergänge sind kritisch, weil Unternehmen sie oft nicht vollständig kontrollieren.

Ein guter Testfall ist deshalb nicht „Startseite öffnen“, sondern zum Beispiel:

1. Produkt suchen oder Leistung auswählen.
2. Detailseite verstehen.
3. Formular oder Warenkorb bedienen.
4. Fehler absichtlich auslösen.
5. Fehler beheben.
6. Prozess abschließen.
7. Bestätigung lesen oder speichern.

Wenn dieser Ablauf ohne Maus, bei starkem Zoom und mit Screenreader verständlich bleibt, ist die Website deutlich näher an echter Barrierefreiheit.

Checkliste: Was Unternehmen 2026 konkret prüfen sollten

Eine barrierefreie Website entsteht am besten in Stufen. Die folgende Checkliste hilft bei Bestandsaufnahme, Priorisierung und Umsetzung.

Design und Layout:

1. Sind Kontraste für Text, Buttons, Formularfelder und Statusmeldungen ausreichend?
2. Funktioniert die Seite bei 200 Prozent Zoom ohne horizontales Scrollen in zentralen Bereichen?
3. Sind Fokuszustände sichtbar, konsistent und nicht nur farblich erkennbar?
4. Sind Klickflächen groß genug und auf Mobilgeräten gut erreichbar?
5. Werden Informationen nicht ausschließlich über Farbe, Position oder Iconform vermittelt?

Technik und Bedienung:

6. Ist die komplette Website mit Tastatur bedienbar?
7. Ist die Tab-Reihenfolge logisch?
8. Haben interaktive Elemente korrekte Rollen, Namen und Zustände?
9. Funktionieren Menüs, Filter, Tabs, Akkordeons und Dialoge mit Screenreader und Tastatur?
10. Gibt es Skip-Links oder andere Wege, wiederkehrende Bereiche zu überspringen?
11. Sind Animationen kontrollierbar oder respektieren reduzierte Bewegungseinstellungen?

Content und Redaktion:

12. Gibt es genau eine H1 und eine logische Überschriftenstruktur?
13. Sind Linktexte eindeutig, statt nur „mehr erfahren“ oder „hier“ zu sagen?
14. Haben informative Bilder sinnvolle Alt-Texte?
15. Sind Tabellen korrekt aufgebaut und nicht für Layoutzwecke missbraucht?
16. Sind Dokumente, Downloads und eingebettete Medien zugänglich oder durch HTML-Inhalte ergänzt?

Formulare und Prozesse:

17. Sind alle Felder mit sichtbaren Labels versehen?
18. Werden Pflichtfelder, Hilfetexte und Fehler verständlich ausgegeben?
19. Bleiben Eingaben erhalten, wenn ein Fehler auftritt?
20. Ist der gesamte Prozess auch ohne Maus und ohne perfekte Sicht nutzbar?
21. Werden Zeitlimits, Captchas oder Uploads so gestaltet, dass Nutzer nicht ausgeschlossen werden?

Diese Liste ersetzt keinen vollständigen WCAG-Test, aber sie zeigt schnell, ob die Website strukturelle Probleme hat. In vielen Projekten lassen sich damit die wichtigsten Risiken priorisieren.

Accessibility Helper in Bajorat Media | Cockpit: Unterstützung für Besucher und Betreiber

Bajorat Media | Cockpit enthält mit dem Accessibility Helper ein kostenloses Tool, das Webseitenbetreiber bei Barrierefreiheit unterstützt. Der Helper kann Besuchern unter anderem bei Kontrasten, Schriftgrößen und Bedienbarkeit helfen und gehört zur Plattform Bajorat Media | Cockpit mit weiteren Website-, SEO-, Monitoring-, Datenschutz- und KI-Tools.

Wichtig ist die richtige Einordnung: Der Accessibility Helper ist ein nützlicher Baustein, aber kein Ersatz für barrierefreies Webdesign, semantisches HTML und geprüfte Formulare. Er kann die Nutzung verbessern und Barrieren reduzieren, während die eigentliche Qualitätsarbeit in Struktur, Code, Content und Prozessen liegt.

Für Unternehmen ist die Kombination interessant:

• Accessibility Helper für zusätzliche Nutzerunterstützung.
• Tools in Bajorat Media | Cockpit für Website-Prüfung, Monitoring und Aufgabenorganisation.
• Fachliche Umsetzung über barrierefreies Webdesign und Konzeption sowie spezialisierte Accessibility-Audits.
• Laufende Prüfung bei Relaunches, neuen Formularen, Kampagnen-Landingpages und Shop-Anpassungen.

So wird Barrierefreiheit nicht als einmaliges Projekt behandelt, sondern als Bestandteil des Website-Betriebs.

Wie ein realistischer Umsetzungsprozess aussieht

Viele Unternehmen unterschätzen den Umfang, weil sie Barrierefreiheit erst am Ende prüfen. Dann werden Fehler teuer: Komponenten müssen neu gebaut, Farben neu definiert, Formulare umstrukturiert und Inhalte nachbearbeitet werden. Besser ist ein Prozess, der Accessibility früh einplant.

Ein praxistauglicher Ablauf:

1. Betroffenheit und Zielniveau klären: BFSG-Relevanz, WCAG-Ziel, kritische Nutzerprozesse.
2. Seitentypen inventarisieren: Startseite, Leistungen, Blog, Shop, Checkout, Formulare, Login, Downloads.
3. Stichprobe manuell prüfen: Tastatur, Screenreader, Zoom, Kontrast, mobile Nutzung.
4. Automatisierte Tests hinzunehmen, aber nicht als alleinige Wahrheit nutzen.
5. Designsystem anpassen: Farben, Fokus, Buttons, Formulare, Komponenten, Zustände.
6. Templates und Komponenten technisch überarbeiten.
7. Redaktion schulen: Überschriften, Alt-Texte, Linktexte, Tabellen, PDFs.
8. Kritische Prozesse erneut testen.
9. Befunde dokumentieren und Prioritäten festlegen.
10. Barrierefreiheit in künftige Website-Änderungen integrieren.

Bei Relaunches sollte dieser Ablauf Teil der Konzeption sein. Bei bestehenden Websites ist ein Audit oft der bessere Einstieg: Erst messen, dann priorisieren, dann die stärksten Hebel umsetzen. Das gilt besonders, wenn zugleich Performance, Datenschutz, SEO oder Conversion-Optimierung bearbeitet werden. Accessibility wirkt in diese Bereiche hinein, statt neben ihnen zu stehen.

Ein Audit sollte die Befunde priorisieren. Nicht jeder Fehler hat dieselbe Wirkung. Ein fehlender Alt-Text bei einem dekorativen Bild ist anders zu bewerten als ein nicht bedienbarer Checkout-Button. Sinnvoll ist eine Einstufung nach Schwere, Häufigkeit und Prozessrelevanz:

Priorität	Bedeutung	Beispiel
Kritisch	Nutzer können einen zentralen Prozess nicht abschließen.	Formular ist ohne Maus nicht absendbar.
Hoch	Nutzer werden stark behindert oder verlieren Orientierung.	Fehlermeldungen sind nicht dem Feld zugeordnet.
Mittel	Nutzung ist möglich, aber unnötig schwierig.	Fokuszustände sind schwach sichtbar.
Niedrig	Qualität oder Verständlichkeit leidet, Prozess bleibt nutzbar.	Alt-Text ist vorhanden, aber zu allgemein.

Diese Priorisierung hilft Teams, Barrierefreiheit nicht als unüberschaubare Mängelliste zu erleben. Zuerst werden Blocker in Kernprozessen behoben, danach wiederkehrende Komponenten, anschließend redaktionelle und dokumentenbezogene Themen.

Was automatisierte Tools leisten und wo manuell geprüft werden muss

Automatisierte Accessibility-Checks finden viele technische Fehler: fehlende Labels, Kontrastprobleme, ARIA-Fehler, leere Buttons oder fehlende Alt-Attribute. Sie sind schnell und eignen sich gut für wiederkehrende Qualitätssicherung. Sie erkennen aber nicht zuverlässig, ob ein Alt-Text fachlich sinnvoll ist, ob ein Prozess verständlich bleibt oder ob ein Dialog in realer Nutzung Orientierung bietet.

Manuelle Tests bleiben deshalb notwendig:

• Tastaturbedienung über komplette Prozesse.
• Screenreader-Test für Navigation, Formulare und Dialoge.
• Prüfung von Fehlermeldungen und Hilfetexten.
• Verständlichkeit von Sprache und Struktur.
• Mobile Nutzung mit Zoom und veränderten Systemeinstellungen.
• Prüfung von Medien, PDFs und eingebetteten Diensten.

Wer im eigenen Team startet, kann zunächst die wichtigsten Templates und Prozesse prüfen. Für eine belastbare Bewertung empfiehlt sich anschließend ein professioneller Audit, besonders bei rechtlich relevanten digitalen Dienstleistungen.

Barrierefreiheit dauerhaft im Betrieb verankern

Nach einem Audit ist die Website nicht dauerhaft fertig. Neue Inhalte, Landingpages, Formulare, Shop-Erweiterungen, Cookie-Banner, Videos oder PDFs können wieder neue Barrieren erzeugen. Deshalb braucht Barrierefreiheit einen Platz im laufenden Betrieb.

Für Unternehmen funktioniert das am besten, wenn Verantwortlichkeiten klar verteilt sind:

• Design definiert Kontraste, Fokuszustände, Komponenten und responsive Zustände.
• Entwicklung sichert semantisches HTML, Tastaturbedienung, ARIA-Logik und technische Tests.
• Redaktion achtet auf Überschriften, Linktexte, Alternativtexte, Tabellen und verständliche Sprache.
• Marketing prüft Landingpages, Kampagnenformulare, Videos und Tracking-Einbettungen.
• Projektverantwortliche entscheiden, welche Befunde wann umgesetzt werden.

Barrierefreiheit sollte außerdem Teil von Abnahmeprozessen werden. Eine neue Komponente gilt dann nicht nur als fertig, wenn sie gut aussieht, sondern wenn sie mit Tastatur bedienbar ist, Fokuszustände zeigt, verständliche Labels hat und keine offensichtlichen Screenreader-Probleme erzeugt. Bei größeren Änderungen lohnt sich ein kurzer Re-Test der wichtigsten Nutzerwege.

Für Teams mit begrenzten Ressourcen ist ein realistischer Rhythmus besser als Perfektionsdruck: kritische Prozesse sofort verbessern, Komponenten beim nächsten Relaunch oder Designsystem-Update nachziehen, redaktionelle Standards in den Alltag übernehmen und größere Audits regelmäßig wiederholen.

Fazit: Barrierefreiheit gehört in den Website-Betrieb

Eine barrierefreie Website 2026 ist nicht nur eine Reaktion auf BFSG und WCAG. Sie ist ein Zeichen dafür, dass digitale Angebote ernsthaft für reale Menschen gebaut werden. Unternehmen profitieren von klareren Strukturen, besseren Formularen, verständlicheren Inhalten, stabileren Komponenten und einer Website, die auch unter schwierigen Nutzungsbedingungen funktioniert.

Der beste Zeitpunkt für Accessibility ist die Konzeption. Der zweitbeste ist ein strukturierter Audit der bestehenden Website. Mit einem klaren Prüfprozess, dem kostenlosen Accessibility Helper in Bajorat Media | Cockpit und fachlicher Umsetzung durch Design, Entwicklung und Redaktion lässt sich Barrierefreiheit in überschaubare Schritte übersetzen.