BFSG für WordPress: Website barrierefrei machen

Barrierefreiheit sollte bereits bei Komponenten, Formularen und Inhaltsstruktur berücksichtigt werden. Für die technische Projektabgrenzung verweist die Leistungsseite Website erstellen lassen auf die dafür benötigten Inhalte und Zuständigkeiten. Die rechtliche Einordnung des konkreten Angebots ist davon getrennt zu prüfen.

Hinweis: Zahlenangaben ohne Quellenlink in diesem Beitrag sind angenommene Werte für Rechenbeispiele oder eigene Einschätzungen (Stand 10/2026) und ohne Gewähr. Keine Rechtsberatung: Ob das BFSG für Ihr Angebot gilt, klären Sie im Einzelfall.

Warum ist eine barrierefreie Website 2026 nach WCAG 2.1 AA kein Nice-to-have mehr?

Das BFSG gilt seit dem 28. Juni 2025 unter anderem für Dienstleistungen im elektronischen Geschäftsverkehr, die über Websites oder Apps im Hinblick auf einen Verbrauchervertrag erbracht werden. Dazu zählen typischerweise Online-Shops und online buchbare Leistungen. Eine reine Unternehmenswebsite fällt nicht automatisch darunter. Kleinstunternehmen, die Dienstleistungen anbieten, sind nach § 3 Absatz 3 BFSG grundsätzlich ausgenommen. Maßgeblich sind Angebot, Zielgruppe und Unternehmensgröße. Die FAQ der Bundesfachstelle Barrierefreiheit erläutert den Anwendungsbereich und die Anforderungen an den elektronischen Geschäftsverkehr. Dieser Beitrag ersetzt keine Rechtsberatung.

Die Ursache liegt in der Technik: fehlende Alt-Texte, nicht tastaturnavigierbare Formulare, schlechte Kontraste, keine ARIA-Labels. Ein strukturiertes WCAG 2.1 AA-Audit deckt diese Probleme auf. Meist lässt sich das reparieren, wenn die Basis nicht völlig marode ist.

Für SEO und UX ist Barrierefreiheit kein Nebenthema. Google rechnet seit 2021 Core Web Vitals ins Ranking ein, und viele Accessibility-Fehler (fehlende Heading-Hierarchie, unleserliche Schriftgrößen, keine Fokus-Indikatoren) zerstören die User Experience für alle. Die WCAG 2.1 Standards sind keine Spezial-Lösung für eine Minderheit. Das sind Best Practices für wartbaren, zukunftssicheren Code. Wer 2026 eine Website neu baut oder relauncht, sollte Accessibility von Tag eins einplanen. Nicht als Plugin hinterher. Sondern als Teil der Frontend-Entwicklung.

Welche BFSG-, EN-301-549- und WCAG-2.1-AA-Anforderungen müssen Sie bei einer Website konkret erfüllen?

Dieser technische Vergleich gehört zur Rubrik Webentwicklung auf webentwickler.pro und zeigt, welche gesetzlichen Anforderungen Shop-Betreiber bis zum Stichtag im Juni 2025 technisch umsetzen müssen. Die folgende Tabelle schlüsselt die Pflichten nach dem Barrierefreiheitsstärkungsgesetz (BFSG) und den zugrunde liegenden Standards EN 301 549 sowie WCAG 2.1 AA auf.

Die technische Umsetzung dieser Anforderungen betrifft vor allem die Frontend-Architektur Ihres Shops. Während Standard-Templates oft grundlegende Strukturen liefern, scheitern viele Setups an individuellen Anpassungen im Checkout oder bei komplexen Filtern. Eine saubere Compliance E-Commerce 2026 erfordert daher meist manuelle Korrekturen im Code, um die WCAG-Orientierung sicherzustellen.

Welche 8 WCAG-Prüfpunkte bei Tastatur, Kontrast und Formularen zuerst relevant sind

Dieser technische Leitfaden ist Teil der Rubrik Webentwicklung auf webentwickler.pro und unterstützt Shop-Betreiber dabei, die Anforderungen des Barrierefreiheitsstärkungsgesetzes (BFSG) systematisch umzusetzen. Die folgende Übersicht fokussiert sich auf die kritischen technischen Prüfpunkte, die oft über die bloße Einhaltung rechtlicher Vorgaben hinausgehen und direkten Einfluss auf die Usability und Conversion-Rate Ihres Onlineshops haben.

Die technische Umsetzung dieser Punkte ist entscheidend für eine rechtlich sorgfältige BFSG Compliance Webseite. Während Standard-Plugins oft nur oberflächliche Korrekturen bieten, erfordern tieferliegende Probleme in der Template-Logik meist manuelle Eingriffe im Code, um eine dauerhafte Barrierefreiheit zu gewährleisten.

Was bringt semantisches HTML, Tastaturnavigation und 200-%-Zoom für Nutzer und Unternehmen wirklich?

Semantisches HTML, Tastaturnavigation und 200-%-Zoom sind keine Compliance-Checkliste, sondern technische Architektur-Entscheidungen, die Conversion, Ladezeit und Informationsarchitektur direkt beeinflussen. Ein <button> statt <div onclick> kostet Sie keine Entwicklungszeit, aber ein Screenreader erkennt ihn sofort. Ein <nav> statt <div class="menu"> gibt Suchmaschinen klare Struktur, ohne dass Sie ein Wort SEO-Text schreiben müssen.

Technische Barrierefreiheit und SEO teilen dieselbe Grundlage: strukturierte, semantische Markup-Architektur. Wenn Sie <h1> bis <h3> konsequent nutzen, profitieren Screenreader-Nutzer (die per Tastatur durch Überschriften springen) und Google (das Ihre Informationsarchitektur besser versteht). Wenn Sie Fokus-Zustände für Tastaturnavigation sauber definieren, reduzieren Sie gleichzeitig Hürden im Checkout für alle, die ohne Maus navigieren.

200-%-Zoom ist kein Edge Case. Ein flexibles Grid-Layout mit relativen Einheiten (rem, em) statt fixen Pixelwerten kostet Sie nichts, wenn Sie es von Anfang an richtig bauen. Nachträglich ein starres Template umzubauen? Je nach Umfang deutlich mehr Entwicklungszeit, die Sie sonst in Conversion-Optimierung stecken könnten.

Tastaturnavigation ist der Lackmustest für saubere Interaktionsarchitektur. Wenn Sie mit Tab durch Ihren Shop navigieren und ein Dropdown-Menü, Modal oder Filter nicht erreichbar ist, haben Sie ein strukturelles Problem. Das betrifft nicht nur Screenreader-Nutzer, sondern auch Power-User und mobile Nutzer mit externer Tastatur. Ein <button> ist per Default fokussierbar. Ein <div onclick> nicht, außer Sie fügen tabindex="0" und role="button" manuell hinzu. Warum den Umweg gehen?

Die Verbindung zwischen SEO und Barrierefreiheit liegt in der Informationsarchitektur. Wenn Sie <main>, <aside>, <article> nutzen, versteht Google sofort, was Hauptinhalt ist. Wenn Sie alt-Attribute für Produktbilder schreiben, indexiert Google den Kontext, und Screenreader lesen ihn vor. Wenn Sie <label> mit <input> verknüpfen, erkennt Google Formulare besser, und Nutzer mit motorischen Einschränkungen können auf das Label klicken.

Ladezeit profitiert direkt von semantischem HTML. Ein <button> braucht kein zusätzliches JavaScript für Klick-Events. Ein <nav> braucht keine CSS-Klasse für Screenreader-Erkennung. Wenn Sie Ihr Layout mit <header>, <main>, <footer> strukturieren statt mit <div class="header">, reduzieren Sie DOM-Komplexität, und damit Rendering-Zeit. Google bewertet einen Largest Contentful Paint (LCP) von höchstens 2,5 Sekunden als gut (Quelle: Google, web.dev), und jedes unnötige Skript kostet Zeit auf diesem Weg.

Die meisten Barrierefreiheits-Overlays (automatische Widgets, die Kontrast und Schriftgröße anpassen) beheben keine strukturellen Probleme. Wenn Ihr HTML keine <label> hat, kann kein Overlay sie nachträglich hinzufügen. Wenn Ihr Modal per display: none versteckt ist, aber kein aria-hidden="true" hat, liest ein Screenreader es trotzdem vor, auch wenn es unsichtbar ist. Ein Code-Audit zeigt Ihnen, wo Ihr HTML strukturell nachgebessert werden muss, statt ein Overlay zu installieren, das das Problem nur visuell kaschiert. Der Preis hängt vom Umfang des Shops und des Prüfkatalogs ab.

Was müssen Sie bei WordPress für BFSG und Barrierefreiheit prüfen?

Bei WordPress entscheidet nicht das CMS allein über Barrierefreiheit, sondern das Zusammenspiel aus Theme, Plugins, Inhalten und individuellen Anpassungen. Die Kennzeichnung „accessibility-ready“ ist laut offiziellem WordPress Theme Handbook keine Garantie für vollständige WCAG-AA-Konformität. Sie bestätigt nur, dass ein Theme die für das WordPress-Verzeichnis definierten Mindestanforderungen erfüllt.

• Theme und Navigation: Landmarks, Überschriftenfolge, Skip-Link, sichtbarer Fokus und vollständige Tastaturbedienung prüfen.
• Plugins und Formulare: Beschriftungen, Fehlermeldungen, Dialoge, Cookie-Banner, Suche und Checkout ohne Maus testen.
• Redaktion: Alt-Texte, verständliche Linktexte, Untertitel, Tabellenüberschriften und klare Sprache verbindlich im Prozess verankern.
• Updates: Theme- oder Plugin-Updates mit automatisierten Scans und manuellen Tastaturtests absichern.
• Nachweis: Prüfdatum, geprüfte Nutzerwege, bekannte Einschränkungen und Korrekturen dokumentieren.

Für Shops und Buchungsstrecken ist nicht nur eine einzelne Seite relevant. Die Bundesfachstelle weist darauf hin, dass die Anforderungen in der Regel die gesamte Website oder App betreffen können. Prüfen Sie deshalb mindestens Produktsuche, Produktdetail, Warenkorb, Anmeldung, Zahlung, Bestätigung und Kontakt.

In welchen 6 Schritten können Sie eine Website barrierefrei machen statt später teuer nachzurüsten?

Barrierefreiheit ist im deutschen eCommerce keine freiwillige Option mehr, sondern durch das Barrierefreiheitsstärkungsgesetz (BFSG) für viele Unternehmen ab Juni 2025 verpflichtend. Dieser Artikel gehört zur Rubrik Webentwicklung auf webentwickler.pro und zeigt, wie Sie den Prozess strukturiert angehen, um teure Nachbesserungen oder Bußgelder zu vermeiden.

Wer die Barrierefreiheit erst nachträglich in ein starres Template „hineinzuquetschen“ versucht, zahlt oft deutlich mehr Entwicklungsstunden im Vergleich zu einem sauberen, initialen Aufbau. Die Kosten einer professionellen Website hängen stark davon ab, ob Barrierefreiheit von Beginn an in Komponenten und Abnahme eingeplant ist oder bestehende DOM-Strukturen, Formulare und Kontraste nachträglich korrigiert werden müssen.

1. Technisches Audit und Bestandsaufnahme durchführen. Bevor Sie eine einzige Zeile Code ändern, prüfen Sie den Ist-Zustand mit Tools wie Lighthouse oder Axe-Core. Sie identifizieren fehlende Alt-Texte, falsche Überschriften-Hierarchien (H1-H6) und mangelhafte Tastatur-Navigation.
2. Barrierefreies Design-System festlegen. Barrierefreiheit beginnt im Grafikprogramm. Sie definieren Kontrastverhältnisse von mindestens 4,5:1 für Fließtext und stellen sicher, dass interaktive Elemente wie Buttons klare Fokus-Zustände besitzen.
3. Semantisches HTML und ARIA-Labels umsetzen. In der Entwicklung verzichten Sie auf „Div-Suppe“ und nutzen echte HTML5-Tags wie <main>, <nav> und <button>. Wo Standard-HTML nicht ausreicht, ergänzen Sie ARIA-Attribute (Accessible Rich Internet Applications), damit Screenreader verstehen, was in dynamischen Elementen wie Warenkorb-Layovern passiert.
4. Content-Strukturen barrierefrei aufbereiten. Barrierefreiheit ist auch Redaktionsarbeit. Sie pflegen für jedes Bild einen aussagekräftigen Alt-Text ein und achten darauf, dass Linktexte wie „hier klicken“ durch beschreibende Anker wie „Datenblatt als PDF herunterladen“ ersetzt werden. Dies verbessert nicht nur die Accessibility, sondern zahlt direkt auf Ihr technisches SEO ein, da Suchmaschinen-Crawler den Kontext besser erfassen.
5. Iterative Tests mit assistiven Technologien. Sie sollten Ihren Checkout-Prozess mindestens einmal selbst nur mit der Tastatur und einem Screenreader (wie NVDA oder VoiceOver) durchlaufen.
6. Laufende Wartung und Monitoring etablieren. Barrierefreiheit ist kein einmaliger Zustand. Jedes neue Plugin, jedes Banner und jedes Update in JTL oder Shopware kann die Konformität brechen. Sie integrieren Accessibility-Checks in Ihre CI/CD-Pipeline oder nutzen Monitoring-Tools, die Sie bei neuen Fehlern sofort benachrichtigen.

Wer seine technische Basis stabil hält, stößt oft auch auf Themen der Rubriken Web-Performance und SEO, dort finden Sie konkrete Messprotokolle zur weiteren Optimierung.

Wie unterscheiden sich Relaunch, Nachrüstung und Accessibility-Widget bei Kosten, Risiko und BFSG-Sicherheit?

Die Wahl der richtigen Strategie für die Barrierefreiheit hängt stark von Ihrem bestehenden System und Ihrem Budget ab. Während ein technischer Relaunch die sauberste Basis bietet, suchen viele Shop-Betreiber nach Wegen, bestehende Templates nachzurüsten. Dieser Vergleich ordnet die Optionen technisch und rechtlich ein, damit Sie die website erstellen lassen kosten besser kalkulieren können.

Warum warnen Experten 2026 vor One-Click-Lösungen und empfehlen manuelle Audits plus Monitoring?

One-Click-Lösungen scannen die Oberfläche, nicht die Struktur darunter, und decken deshalb nur einen Teil der Anforderungen ab. Ein automatisiertes Tool prüft, ob ein Alt-Text existiert. Nicht, ob er den Kontext beschreibt. Es erkennt Farbkontraste. Nicht, ob die Tastatur-Navigation logisch funktioniert. Sie liefern eine Checkliste, keine Diagnose.

Ein manuelles Website-Accessibility-Audit deckt auf, was Automaten übersehen: fehlende Landmark-Regionen, inkonsistente Heading-Hierarchie, JavaScript-Overlays ohne Fokus-Management. Diese Probleme tauchen in automatisierten Scans nicht auf, sie brauchen Kontext und echten Nutzerfluss. Ein erfahrener Auditor testet mit Tastatur, Screenreader und Zoom. Er dokumentiert, wo die Architektur bricht. Die Kosten hängen vom Umfang des Shops ab, lassen Sie sich ein Angebot mit klar definiertem Prüfumfang geben. Ertrag: eine Roadmap mit klaren Prioritäten: kritische Blocker (Checkout, Formulare) vor kosmetischen Fixes (Farbkontraste in der Footer-Navigation). Das BFSG schreibt kein bestimmtes Audit vor, verlangt aber, dass die Anforderungen tatsächlich erfüllt sind, und für Anbieter ist eine nachvollziehbare Dokumentation hilfreich. Ein Widget liefert diese Dokumentation der Maßnahmen nicht.

Monitoring ist der zweite Baustein: Nach dem Audit brauchen Sie ein System, das neue Inhalte automatisch prüft, bevor sie live gehen. Tools wie Axe DevTools oder Pa11y lassen sich in CI/CD-Pipelines integrieren und blockieren Deployments bei kritischen WCAG-Verstößen. Ein neues Template oder ein Plugin-Update kann die Barrierefreiheit kaputtmachen. Ein Widget läuft dagegen passiv im Frontend und reagiert erst, wenn der Fehler schon produktiv ist. Der echte Unterschied: Audit plus Monitoring kostet Sie einmalig Zeit und Setup. Ein Widget verursacht dagegen dauerhaft laufende Lizenzkosten, und Sie behalten die Kontrolle über Ihre Code-Basis nicht.

Welche typischen Barrieren in CMS, Themes und Redaktionsprozessen machen die Umsetzung unnötig teuer?

Veraltete Systeme machen es schlimmer. Ältere CMS-Versionen und Shop-Templates erzeugen häufig kein semantisches Markup und nutzen <div> statt <button> für interaktive Elemente. Ob eine konkrete Version Landmarks und ARIA-Attribute unterstützt, prüfen Sie in der Dokumentation des jeweiligen Systems. Ein Theme-Update löst strukturelle Mängel nicht automatisch. Wenn das Framework keine ARIA-Attribute unterstützt, bleibt die Seite nicht konform, egal wie viel CSS Sie anpassen.

Welcher Grundsatz hinter Universal Design die Usability für alle Nutzer verbessert

Universal Design bedeutet: Produkte und Umgebungen so bauen, dass sie von Anfang an für möglichst viele Menschen funktionieren, ohne Anpassungen, ohne Spezial-Versionen. Das klingt nach Mehraufwand. Ist es aber nicht. Eine breite Rampe hilft dem Rollstuhlfahrer wie dem Elternteil mit Kinderwagen. Große Schaltflächen helfen Senioren und Menschen mit motorischen Einschränkungen, aber auch vielen jungen Menschen, die lieber auf größere Ziele tippen. Nach Angaben der WHO leben weltweit rund 1,3 Milliarden Menschen mit einer erheblichen Beeinträchtigung (16 Prozent der Weltbevölkerung; Quelle: WHO, Fact Sheet „Disability“). Wer Universal Design ernsthaft umsetzt, erreicht diese Menschen nicht durch separate Lösungen, sondern durch besseres Design für alle.

Die Grundlage bilden sieben Prinzipien vom Center for Universal Design der North Carolina State University: gleichberechtigte Nutzung, Flexibilität, einfache Bedienung, wahrnehmbare Informationen, Fehlertoleranz, geringer körperlicher Aufwand, angemessene Größe und Platz. Kontraste von mindestens 4,5:1 (WCAG 2.1 Standard) verbessern nicht nur die Lesbarkeit für Menschen mit Sehschwäche, sie helfen auch bei Sonnenlicht auf dem Smartphone. Tastaturnavigation? Macht Menschen mit motorischen Einschränkungen die Bedienung möglich, erspart aber auch Power-Usern die Maus. Jede dieser Maßnahmen löst ein echtes Problem für mehrere Nutzergruppen gleichzeitig.

Warum? Weil semantisches HTML, saubere Struktur und klare Informationsarchitektur nicht nur Screenreadern helfen, sondern erleichtern auch Google-Crawlern die Verarbeitung. Universal Design von Anfang an einzubauen bedeutet: keine teuren Nachbesserungen später, keine separaten Barrierefrei-Versionen, keine technischen Schulden. Eine solide Basis.

Was Sie jetzt mitnehmen

Ein Relaunch lohnt sich besonders, wenn Ihr Shop auf veralteten Templates läuft, die kein semantisches HTML5 nutzen, oder wenn Sie ohnehin migrieren (JTL 4 zu 5, Shopware 5 zu 6). Dann bauen Sie WCAG-Orientierung von Anfang an ein, statt später nachzurüsten. Der Grund ist simpel. Sie müssen bestehende Templates aufbrechen, Farbkontraste neu berechnen, Formulare umbauen und alle Bilder mit Alt-Texten ausstatten. Bei einem Relaunch integrieren Sie diese Anforderungen direkt in Design und Code.

Das BFSG gilt für bestimmte Produkte und Dienstleistungen im Verbrauchergeschäft, darunter Verbraucherverträge im elektronischen Geschäftsverkehr. Kleinstunternehmen (weniger als zehn Beschäftigte und höchstens 2 Mio. EUR Jahresumsatz oder Bilanzsumme), die Dienstleistungen anbieten, sind nach § 3 Abs. 3 BFSG ausgenommen. Als Maßstab dient WCAG 2.1 Level AA über die EN 301 549. Das heißt konkret: Ihr Shop muss also Tastaturnavigation, Screenreader-Kompatibilität, Farbkontraste von mindestens 4,5:1 für Normaltexte, sichtbare Fokus-Indikatoren und verständliche Fehlermeldungen. Verstöße können je nach Fall mit Bußgeldern bis zu 100.000 Euro geahndet werden (§ 37 BFSG). Hinzu können Abmahnungen von Wettbewerbern und Verbraucherschutzverbänden kommen. Das ist ein Risiko, das Shop-Betreiber oft unterschätzen. Ob und wie das BFSG Ihr Angebot betrifft, sollten Sie im Einzelfall prüfen lassen.

Frühe Umsetzung vermeidet teure technische Schulden. Nehmen wir ein Beispiel: Ein JTL-Shop 5 mit Custom-Template ohne ARIA-Labels braucht eine komplette Template-Überarbeitung inklusive Screenreader-Tests (NVDA, JAWS). Das kostet nachträglich meist deutlich mehr Entwicklerstunden, als wenn Sie die WCAG-Orientierung direkt in den Relaunch einbauen, weil dann keine Legacy-Strukturen im Weg stehen. Barrierefreiheit und Performance sollten gemeinsam geprüft werden, sind aber unterschiedliche Qualitätsziele. Semantisches HTML und schlanke Komponenten können beide unterstützen. Ob sich Core Web Vitals verbessern, muss mit Felddaten und Labortests gemessen werden.

Stanislav Tonkich

Webentwickler, SEO und KI-Automation

Seit 1995 in der IT, seit 2018 Webentwickler, seit 2023 im eCommerce. Ich baue Individuallösungen, automatisiere Abläufe mit KI und arbeite an der Sichtbarkeit in Google und in KI-Suchen.

Mehr über Stanislav Tonkich →