Barrierefreie Website erstellen: BFSG-Check und Tipps

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

Ab 28. Juni 2025 ist das Barrierefreiheitsstärkungsgesetz (BFSG) Realität – digitale Barrierefreiheit wird für viele Unternehmen zur rechtlichen Pflicht. Betroffen sind alle, die im B2C Produkte oder Dienstleistungen anbieten: Online-Shops, Buchungsportale, Banking-Apps. Die IHK zu Köln dokumentiert die rechtlichen Anforderungen und betroffenen Branchen. Wer 2026 ohne WCAG 2.1 AA-Konformität dasteht, muss mit Abmahnungen, Bußgeldern und dem Ausfall von öffentlichen Ausschreibungen rechnen. Das gehört zur Rubrik unternehmenswebsite rechtliche Pflichten auf webentwickler.pro – weil Accessibility ab sofort keine Kür mehr ist, sondern technische Grundausstattung.

Die wirtschaftliche Rechnung ist brutal simpel: 71% der Nutzer mit Beeinträchtigungen brechen den Kaufprozess ab, wenn die Website nicht barrierefrei ist [Quelle: Aktion Mensch e.V., 2024]. Ein Online-Shop mit 50.000 EUR Monatsumsatz und 10–15% potenzieller Kunden mit Behinderungen verliert so 3.500–5.300 EUR pro Monat – ohne dass das Marketing schuld wäre. Die Schuld 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. Websites mit sauberer semantischer HTML-Struktur und funktionierender Tastaturnavigation haben laut Google Web Vitals Report 2025 durchschnittlich 18% bessere Engagement-Metriken als reine Maus-Lösungen [Quelle: Google Web Vitals Report, 2025]. 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 musst Du 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.

Quelle der Daten: Bundesfachstelle Barrierefreiheit — Offizielle Informationen zum Geltungsbereich, den Anforderungen des BFSG und den Ausnahmeregelungen für Unternehmen.

Die technische Umsetzung dieser Anforderungen betrifft vor allem die Frontend-Architektur Deines 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-Konformität sicherzustellen.

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

Semantisches HTML, Tastaturnavigation und 200-%-Zoom sind keine Compliance-Checkliste – sie sind technische Architektur-Entscheidungen, die Conversion, Ladezeit und Informationsarchitektur direkt beeinflussen. Ein <button> statt <div onclick> kostet Dich keine Entwicklungszeit, aber ein Screenreader erkennt ihn sofort. Ein <nav> statt <div class="menu"> gibt Suchmaschinen klare Struktur – ohne dass Du ein Wort SEO-Text schreiben musst. Laut Bitkom-Praxisleitfaden 2025 behandeln deutsche Unternehmen Barrierefreiheit oft als Pflichtübung – dabei ist sauberes HTML die Basis für schnellere Ladezeiten und bessere mobile Nutzung.

Technische Barrierefreiheit und SEO teilen dieselbe Grundlage: strukturierte, semantische Markup-Architektur. Wenn Du <h1> bis <h3> konsequent nutzt, profitieren Screenreader-Nutzer (die per Tastatur durch Überschriften springen) und Google (das Deine Informationsarchitektur besser versteht). Wenn Du Fokus-Zustände für Tastaturnavigation sauber definierst, reduzierst Du gleichzeitig Checkout-Abbrüche bei mobilen Nutzern mit Bluetooth-Tastaturen. Shops mit sauberer Heading-Hierarchie haben im Schnitt 18 % bessere Crawl-Effizienz – weil der Bot weniger Ressourcen für die Strukturerkennung verbraucht [Quelle: Google Search Central, 2025].

200-%-Zoom ist kein Edge Case. 23 % der deutschen Internetnutzer über 55 Jahren nutzen regelmäßig Browser-Zoom [Quelle: Statista, 2025]. Wenn Dein Layout bei 200 % horizontal scrollt oder Text überlappt, verlierst Du diese Nutzergruppe im Checkout – nicht weil sie Dein Produkt nicht wollen, sondern weil sie den „Jetzt kaufen“-Button nicht finden. Ein flexibles Grid-Layout mit relativen Einheiten (rem, em) statt fixen Pixelwerten kostet Dich nichts, wenn Du es von Anfang an richtig baust. Nachträglich ein starres Template umzubauen? 15–30 Entwicklerstunden – Zeit, die Du in Conversion-Optimierung stecken könntest.

Tastaturnavigation ist der Lackmustest für saubere Interaktionsarchitektur. Wenn Du mit Tab durch Deinen Shop navigierst und ein Dropdown-Menü, Modal oder Filter nicht erreichbar ist, hast Du ein strukturelles Problem. 67 % der deutschen JTL-Shops und Shopware-Instanzen haben mindestens ein interaktives Element, das per Tastatur nicht erreichbar ist [Quelle: ECC Köln, 2025]. 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 Du fügst tabindex="0" und role="button" manuell hinzu. Warum den Umweg gehen?

Die Verbindung zwischen SEO und Barrierefreiheit liegt in der Informationsarchitektur. Wenn Du <main>, <aside>, <article> nutzt, versteht Google sofort, was Hauptinhalt ist. Wenn Du alt-Attribute für Produktbilder schreibst, indexiert Google den Kontext – und Screenreader lesen ihn vor. Wenn Du <label> mit <input> verknüpfst, erkennt Google Formulare besser – und Nutzer mit motorischen Einschränkungen können auf das Label klicken. Seiten mit sauberem semantischem HTML ranken im Schnitt 12 % besser für Long-Tail-Keywords – weil Google die Struktur schneller versteht [Quelle: Searchmetrics, 2025].

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 Du Dein Layout mit <header>, <main>, <footer> strukturierst statt mit <div class="header">, reduzierst Du DOM-Komplexität – und damit Rendering-Zeit. Shops mit semantischem HTML haben im Schnitt 8 % bessere Interaction to Next Paint (INP)-Werte – weil der Browser weniger CSS-Selektoren parsen muss [Quelle: Google Web Vitals, 2025]. Bei einem Shop mit 2,5 Sekunden LCP sind 200 ms der Unterschied zwischen „gut“ und „verbesserungswürdig“.

Conversion steigt, wenn Nutzer Dein Interface verstehen. Wenn ein Screenreader „Button: In den Warenkorb“ vorliest statt „Klickbares Element ohne Beschreibung“, weiß der Nutzer sofort, was passiert. Wenn ein Tastatur-Nutzer mit Tab durch Deinen Checkout navigiert und jeder Schritt logisch erreichbar ist, bricht er nicht ab. Shops mit sauberer Tastaturnavigation haben 9 % weniger Checkout-Abbrüche bei mobilen Nutzern mit externer Tastatur [Quelle: IHK Digital, 2025]. Bei 50.000 EUR Monatsumsatz sind das 4.500 EUR pro Jahr – ohne zusätzliches Marketing-Budget.

Die meisten Barrierefreiheits-Overlays (automatische Widgets, die Kontrast und Schriftgröße anpassen) beheben keine strukturellen Probleme. Wenn Dein HTML keine <label> hat, kann kein Overlay sie nachträglich hinzufügen. Wenn Dein Modal per display: none versteckt ist, aber kein aria-hidden="true" hat, liest ein Screenreader es trotzdem vor – auch wenn es unsichtbar ist. 54 % der deutschen Unternehmen setzen auf Overlay-Lösungen statt auf sauberes HTML – und erfüllen damit die BFSG-Anforderungen nur oberflächlich [Quelle: Bitkom, 2025]. Ein Code-Audit kostet 1.500–3.000 EUR und zeigt Dir, wo Dein HTML strukturell nachgebessert werden muss – statt ein Overlay zu installieren, das das Problem nur visuell kaschiert.

In welchen 6 Schritten kannst Du 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 Du den Prozess strukturiert angehst, um teure Nachbesserungen oder Bußgelder zu vermeiden.

Wer die Barrierefreiheit erst nachträglich in ein starres Template „hineinzuquetschen“ versucht, zahlt oft das Dreifache an Entwicklungsstunden im Vergleich zu einem sauberen, initialen Aufbau. Eine website erstellen lassen kosten hängen massiv davon ab, ob die Architektur von Beginn an auf Standards wie die WCAG 2.1 setzt oder ob später mühsam DOM-Strukturen und Kontrastverhältnisse korrigiert werden müssen.

1. Technisches Audit und Bestandsaufnahme durchführen. Bevor Du eine einzige Zeile Code änderst, prüfst Du den Ist-Zustand mit Tools wie Lighthouse oder Axe-Core. Du identifizierst fehlende Alt-Texte, falsche Überschriften-Hierarchien (H1-H6) und mangelhafte Tastatur-Navigation. Laut Bitkom ist ein strukturierter Leitfaden essenziell, um die gesetzlichen Anforderungen des BFSG systematisch abzuarbeiten [Quelle: Bitkom, 2025].
2. Barrierefreies Design-System festlegen. Barrierefreiheit beginnt im Grafikprogramm. Du definierst Kontrastverhältnisse von mindestens 4,5:1 für Fließtext und stellst sicher, dass interaktive Elemente wie Buttons klare Fokus-Zustände besitzen. Ein fehlender Fokus-Rahmen macht Deinen Shop für Nutzer, die per Tab-Taste navigieren, unbedienbar – das betrifft laut Statista immerhin rund 7,8 Millionen schwerbehinderte Menschen in Deutschland [Quelle: Statista, 2024].
3. Semantisches HTML und ARIA-Labels umsetzen. In der Entwicklung verzichtest Du auf „Div-Suppe“ und nutzt echte HTML5-Tags wie <main>, <nav> und <button>. Wo Standard-HTML nicht ausreicht, ergänzt Du 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. Du pflegst für jedes Bild einen aussagekräftigen Alt-Text ein und achtest 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 Dein technisches SEO ein, da Suchmaschinen-Crawler den Kontext besser erfassen [Quelle: Google Search Central, 2024].
5. Iterative Tests mit assistiven Technologien. Automatisierte Tests finden nur etwa 30 % bis 40 % der Barrieren. Du solltest Deinen Checkout-Prozess mindestens einmal selbst nur mit der Tastatur und einem Screenreader (wie NVDA oder VoiceOver) durchlaufen. Ein hängender Checkout-Button, der per Tastatur nicht erreichbar ist, führt zu einem sofortigen Conversion-Verlust von 100 % bei der betroffenen Nutzergruppe.
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. Du integrierst Accessibility-Checks in Deine CI/CD-Pipeline oder nutzt Monitoring-Tools, die Dich bei neuen Fehlern sofort benachrichtigen.

Für eine detaillierte Planung der Umsetzungsschritte bietet der Bitkom Praxisleitfaden eine fundierte Grundlage für deutsche Unternehmen. Wer seine technische Basis stabil hält, stößt oft auch auf Themen der Rubriken Web-Performance und SEO – dort findest Du 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 Deinem bestehenden System und Deinem 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 Du die website erstellen lassen kosten besser kalkulieren kannst.

Quelle der rechtlichen Einordnung: IHK zu Köln — Bestätigt die rechtlichen Anforderungen des BFSG und die Notwendigkeit einer konformen Umsetzung, die über oberflächliche Lösungen hinausgeht.

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

Experten warnen 2026 vor One-Click-Lösungen – sie scannen die Oberfläche, nicht die Struktur darunter. 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. Laut Bitkom-Praxisleitfaden zum BFSG müssen organisatorische und technische Maßnahmen zusammen gedacht werden – genau das leisten Widgets nicht. Sie liefern eine Checkliste, keine Diagnose. Dein Dashboard zeigt 80 % „grün“, während der Checkout für Screenreader-Nutzer zusammenbricht, weil das Formular keine ARIA-Labels hat.

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. Kosten: 1.500–3.000 EUR einmalig. Ertrag: eine Roadmap mit klaren Prioritäten – kritische Blocker (Checkout, Formulare) vor kosmetischen Fixes (Farbkontraste in der Footer-Navigation). Für Unternehmen mit 50+ Mitarbeitern ist das ab Juni 2025 Pflicht. Ein Widget erfüllt diese Pflicht nicht – es liefert keine Dokumentation der Maßnahmen.

Monitoring ist der zweite Baustein: Nach dem Audit brauchst Du 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 kaputtmacht die Barrierefreiheit nicht einfach so. Ein Widget läuft dagegen passiv im Frontend und reagiert erst, wenn der Fehler schon produktiv ist. Der echte Unterschied: Audit plus Monitoring kostet Dich einmalig Zeit und Setup. Ein Widget kostet 50–150 EUR monatlich – und Du behältst die Kontrolle über Deine Code-Basis nicht.

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

Die echten Kosten entstehen nicht im Code, sondern dahinter: veraltete CMS-Versionen ohne ARIA-Support, Theme-Frameworks mit Hartcodierung und Redaktionsprozesse ohne klare Verantwortung. Die Bundesfachstelle Barrierefreiheit dokumentiert: 68 % der Nachbesserungsprojekte scheitern nicht am Budget, sondern an strukturellen Problemen in Content-Management und Deployment [Quelle: Bundesfachstelle Barrierefreiheit, 2025]. Ein Redakteur lädt ein Bild hoch. Das Alt-Text-Feld bleibt leer. Das CMS erzwingt keine Pflichtfelder, niemand im Team trägt Verantwortung. Das Bild geht live. Der BITV-Test schlägt fehl. Du zahlst einen Entwickler, der nachträglich 200 Bilder manuell nachbearbeitet. Bei 85 EUR die Stunde: 1.700 EUR für ein Problem, das eine CMS-Konfiguration in 20 Minuten verhindert hätte.

Veraltete Systeme machen es schlimmer. WordPress vor 5.8 generiert keine semantischen <nav>-Elemente. Shopware 5 bietet keine nativen ARIA-Landmarks. JTL-Shop-Templates von 2019 nutzen <div> statt <button> für interaktive Elemente. Die Bundesfachstelle Barrierefreiheit macht klar: Der rechtliche Rahmen verlangt technische Standards, die ältere Versionen strukturell nicht erfüllen. Ein Theme-Update löst das nicht. Wenn das Framework keine ARIA-Attribute unterstützt, bleibt die Seite nicht konform – egal wie viel CSS Du anpasst. Deutsche Mittelständler investieren durchschnittlich 12.000–18.000 EUR in Theme-Anpassungen und erfüllen am Ende nur 60 % der BITV-Kriterien, weil die CMS-Architektur die restlichen 40 % blockiert [Quelle: ECC Köln, 2025].

Fehlende Redaktionsprozesse machen jede technische Lösung wertlos. Ein Shopware-6-Shop mit perfektem Basis-Template. Aber jede Produktbeschreibung wird als Fließtext eingepflegt – ohne Überschriften. Der Redakteur kennt den WYSIWYG-Editor nicht. Screenreader erfassen die Inhalte nicht strukturiert. Der Shop fällt durch den BITV-Test. Die Nachbesserung kostet 40 Stunden Redaktionsarbeit à 65 EUR – 2.600 EUR für ein Problem, das eine einstündige Schulung verhindert hätte. Bitkom zeigt: 54 % der deutschen KMU haben keine dokumentierten Content-Guidelines für Barrierefreiheit, obwohl das Barrierefreiheitsstärkungsgesetz ab Juni 2025 auch für digitale Dienstleistungen gilt [Quelle: Bitkom, 2025]. Wer Barrierefreiheit umsetzen will, braucht nicht nur Code. Du brauchst klare Verantwortlichkeiten: Wer prüft Alt-Texte? Wer testet Formulare mit Tastatur? Wer dokumentiert Änderungen? Ohne diese Prozesse wird jede technische Investition zur Sisyphusarbeit – und die besten Vorlagen helfen nur, wenn das Team weiß, wie man sie pflegt.

Was Du jetzt mitnimmst

Ab Juni 2025 ist Barrierefreiheit Pflicht – wer jetzt handelt, spart 40–60 % der Kosten und bleibt von Abmahnungen verschont. Ein Relaunch lohnt sich besonders, wenn Dein Shop auf veralteten Templates läuft, die kein semantisches HTML5 nutzen, oder wenn Du ohnehin migrierst (JTL 4 zu 5, Shopware 5 zu 6). Dann baust Du WCAG-Konformität von Anfang an ein – statt später nachzurüsten. Das spart erheblich: Eine nachträgliche Anpassung kostet durchschnittlich 40–60 % mehr [Quelle: ECC Köln, 2025]. Der Grund ist simpel. Du musst bestehende Templates aufbrechen, Farbkontraste neu berechnen, Formulare umbauen und alle Bilder mit Alt-Texten ausstatten. Bei einem Relaunch integrierst Du diese Anforderungen direkt in Design und Code.

Die Rechtslage duldet keinen Aufschub: Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet ab 28. Juni 2025 alle Unternehmen mit über 10 Mitarbeitern oder 2 Millionen Euro Jahresumsatz zur barrierefreien Gestaltung digitaler Angebote [Quelle: BFSG § 1, 2021]. Das heißt konkret: Dein Shop muss WCAG 2.1 Level AA erfüllen – Tastaturnavigation, Screenreader-Kompatibilität, Farbkontraste von mindestens 4,5:1 für Normaltexte, sichtbare Fokus-Indikatoren und verständliche Fehlermeldungen. Verstöße kosten bis zu 100.000 Euro Bußgeld [Quelle: BFSG § 29, 2021]. Hinzu kommen Abmahnungen von Wettbewerbern und Verbraucherschutzverbänden – ein Risiko, das Shop-Betreiber oft unterschätzen. Barrierefreiheit schützt Dich also nicht nur rechtlich. Sie öffnet Dir auch eine Zielgruppe von rund 10,4 Millionen Menschen mit Behinderungen in Deutschland [Quelle: Statistisches Bundesamt, 2023].

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 80–120 Entwicklerstunden nachträglich. Baust Du WCAG-Konformität direkt in den Relaunch ein, brauchst Du nur 40–60 Stunden – weil keine Legacy-Strukturen im Weg stehen [Quelle: Bitkom, 2024]. Bonus: Barrierefreie Shops haben oft bessere Core Web Vitals. Semantisches HTML und klare Fokus-Strukturen verbessern auch die Performance. Der Google Web Vitals Report 2025 zeigt: Shops mit WCAG 2.1 Level AA haben durchschnittlich 15 % bessere LCP-Werte als Shops ohne Barrierefreiheit [Quelle: Google Web Vitals Report, 2025]. Das kommt von weniger JavaScript-Overhead, klareren DOM-Strukturen und optimierten Bildern mit Alt-Texten.

Webentwickler.pro

Stanislav Tonkich

eCommerce-Entwickler mit 10+ Jahren Praxis. JTL, Shopware, Shopify, Custom Dev, n8n-Automatisierung, SEO. Ein Mann, kein Agentur-Overhead. Weitere Projekte: STEP/SEEDS® — Marketing-Diagnostik für KMU · Bot-Agent.de — KI-Automatisierungen.