Ein neues Backend-Feld für Mehrsprachigkeit ist schnell angelegt. Der Teil, der danach Monate dauert…
EAA, BFSG und WCAG 2.1 AA: Barrierefreiheit in Komponenten bauen statt in ein einmaliges Audit
Wenn ihr einen Onlineshop oder eine Unternehmensseite in der EU betreibt, habt ihr wahrscheinlich schon eine Version des Standard-Erklärartikels gelesen: European Accessibility Act, BFSG, WCAG 2.1 AA, Bußgelder, Fristen. Dieser Artikel beantwortet, was das Gesetz verlangt. Er beantwortet selten die schwierigere operative Frage: Wenn ihr die Verstöße aus dem letzten Audit behoben habt, was verhindert, dass das nächste Release, die nächste Drittanbieter-Erweiterung oder die nächste Kampagnen-Seite genau diese Verstöße wieder einführt? Genau diese zweite Frage beantwortet dieser Beitrag, keine weitere Zusammenfassung der ersten. Der rechtliche Teil bleibt deshalb bewusst kurz, der Rest ist Praxis: konkrete Schritte, die ihr in eurem Frontend-Team umsetzen könnt, unabhängig davon, welches Backend, welches CMS oder welche Agentur bei euch gerade im Einsatz ist.
Der rechtliche Rahmen, kurz gefasst
Der European Accessibility Act, Richtlinie (EU) 2019/882, gilt EU-weit seit dem 28. Juni 2025. Deutschland hat ihn mit dem Barrierefreiheitsstärkungsgesetz (BFSG) in nationales Recht überführt, das zum selben Datum in Kraft trat. Für die meisten verbraucherorientierten digitalen Produkte und Dienstleistungen, ausdrücklich einschließlich B2C-Onlineshops, definiert die Richtlinie keine eigenen technischen Regeln. Sie verweist auf die harmonisierte Norm EN 301 549, die WCAG 2.1 auf Konformitätsstufe AA vollständig übernimmt, als anerkannten Weg, Konformität nachzuweisen. Kleinstunternehmen, also Unternehmen mit weniger als 10 Beschäftigten und entweder einem Jahresumsatz oder einer Bilanzsumme unter 2 Millionen Euro, sind nach Artikel 4 der Richtlinie von den dienstleistungsbezogenen Pflichten des EAA ausgenommen, wobei diese Ausnahme eng gefasst ist und Produktpflichten grundsätzlich nicht erfasst. In Deutschland wird bereits durchgesetzt: § 37 BFSG sieht Bußgelder von bis zu 10.000 Euro für die meisten Verstöße und bis zu 100.000 Euro für die schwereren Tatbestände vor, und die länderübergreifende Marktüberwachungsstelle für Barrierefreiheit berichtete im Januar 2026, dass die Kontrollen von einer Übergangsphase in eine aktive Überwachungsphase übergegangen sind. Nichts davon ist Rechtsberatung. Ob ein konkretes Angebot in den Anwendungsbereich fällt und welche Ausnahmen greifen, ist eine Frage für eure Rechtsberatung, nicht für einen Blogbeitrag.
Warum das Audit-Projekt-Modell nach dem ersten Durchlauf nicht mehr trägt
Ein Theme-Audit, eine Designsystem-Prüfung, ein externer Barrierefreiheitstest, sie alle folgen demselben Muster: Jemand von außen prüft den aktuellen Zustand, erstellt eine Liste der Befunde, ein Team behebt sie im bestehenden Markup, ein Re-Test bestätigt die Behebung. Dieses Modell beantwortet eine Momentaufnahme. Es beantwortet nicht, was am Tag danach passiert, wenn eine neue Landingpage, ein neuer Checkout-Schritt oder ein Drittanbieter-Widget live geht, ohne dieselbe Prüfung zu durchlaufen. Jede dieser Änderungen kann einen Verstoß wieder einführen, den das letzte Audit bereits geschlossen hatte, weil die Verantwortung für Konformität in der Seite lag, nicht in einer Ebene, die für jede zukünftige Seite gilt. Das Ergebnis ist ein Compliance-Programm, das mit jedem Release-Zyklus wieder näher an null zurückfällt, egal wie gründlich das letzte Audit war.
So verankert ihr Konformität in der Komponenten-Ebene
Schritt 1: Ein barrierefreies Komponenten-Kontrakt pro Komponententyp festhalten
Startet mit einer expliziten Liste, nicht mit einer allgemeinen Policy: Welche Komponenten gibt es, welches barrierefreie Verhalten garantiert jede von ihnen, und was würde diese Garantie brechen. Eine Formular-Komponente garantiert beschriftete Eingabefelder, sichtbare Fehlerzustände und eine definierte Tab-Reihenfolge. Eine Navigations-Komponente garantiert einen Skip-Link und konsistente Landmark-Rollen. Eine Produktkarte garantiert ein beschriebenes Bild und einen sichtbaren Fokus-Zustand. Haltet das als Kontrakt fest, den eine Komponente erfüllt oder nicht, nicht als seitenbezogene Checkliste, die jemand vor jedem Launch manuell durchgeht.
Schritt 2: Kontrast und Typografie als Tokens verankern, nicht als Seiten-Entscheidung
Kontrastfehler entstehen selten aus einer bewussten Design-Entscheidung. Sie entstehen, weil eine Marketerin oder ein Designer einen Farbton wählt, der auf einem Hintergrund gut aussieht und auf einem anderen den WCAG-Mindestwert von 4,5:1 verfehlt. Verlagert kontrastsichere Farbpaare und Schriftgrößen in Design-Tokens, die die Komponenten-Ebene erzwingt, dann erbt eine Kampagnen-Seite eine konforme Palette standardmäßig, statt vor jedem Launch eine manuelle Kontrastprüfung zu brauchen.
Schritt 3: Tastatur- und Fokus-Logik einmal zentralisieren, überall wiederverwenden
Fokus-Reihenfolge und vollständige Tastaturbedienbarkeit gehören zu den häufigsten WCAG-2.1-AA-Verstößen und gleichzeitig zu den schwierigsten, sie über Dutzende Templates hinweg manuell konsistent zu halten. Baut die Logik einmal, innerhalb der geteilten Modal-, Dropdown- und Formular-Komponenten, und jede Seite, die diese Komponenten verwendet, erbt korrektes Verhalten, ohne dass ein Entwickler es jedes Mal neu implementieren muss.
Schritt 4: Jede Komponente vor dem Einsatz auf einer Seite in der CI prüfen
Ein Audit testet die fertige Seite, Wochen oder Monate nach dem Launch. Ein Komponenten-Gate testet den Baustein, bevor er ausgeliefert wird: automatisierte Kontrastprüfungen, ARIA-Attribut-Linting und Tastaturnavigations-Tests, die gegen die isolierte Komponente laufen, innerhalb derselben Pipeline, die bereits eure anderen CI-Checks ausführt. Eine Komponente, die das Gate nicht besteht, erreicht keine Produktion, egal welche Seite sie am Ende nutzen würde und egal welches Team die Seite gebaut hat.
Schritt 5: Verantwortung und einen festen Review-Turnus festlegen, kein Einmal-Projekt
Ein Komponenten-Kontrakt ohne Owner verwässert mit der Zeit. Benennt, wer für die barrierefreie Komponenten-Bibliothek verantwortlich ist, ob das bei einer Frontend-Guild, einem Designsystem-Team oder einer einzelnen Senior-Entwicklerin liegt, und legt einen festen Review-Turnus fest, zum Beispiel jedes Quartal oder mit jedem größeren Design-Token-Release, damit der Kontrakt mit neuer WCAG-Guidance und neuen Komponententypen mitwächst, statt beim Stand des letzten Audits einzufrieren.
Schritt 6: Denselben Kontrakt auf KI-generierte Inhalte und Varianten ausweiten
Wenn KI-Agenten oder Content-Tools Text-Varianten, Layout-Tests oder personalisierte Produktbeschreibungen in eurem Storefront generieren, muss das barrierefreie Komponenten-Kontrakt auch für sie gelten. Ein Agent, der eine Headline für einen A/B-Test austauscht, darf sie nicht in eine Komponente einsetzen, die den Kontrast-Kontrakt bricht, und ein generiertes Produktbild darf die Alt-Text-Pflicht nicht überspringen, nur weil kein Mensch es von Hand geschrieben hat. Diese Grenze direkt in die Agentic Frontend Management Platform einzubauen, statt in einen Review-Schritt, den jemand sich merken muss, hält KI-unterstützte Inhalte innerhalb derselben Konformitäts-Garantie wie alles andere auf der Seite.
Wie sich das auf Plattform-Ebene zeigt
Bei Laioutr bedeuten WCAG-Ready-Komponenten genau das in der Praxis: Formulare, Navigation, Karten und Modals werden einmal gebaut, mit dem oben beschriebenen Kontrakt fest eingebacken, und jeder Content-Management-Workflow, jede neue Seite und jede Composable-DXP-Integration nutzt sie wieder, statt Markup pro Seite neu zu implementieren. Entwicklerinnen und Entwickler besitzen das Komponenten-Kontrakt, und Product- und UX-Teams setzen neue Seiten aus Komponenten zusammen, die die Garantie bereits mitbringen, statt Barrierefreiheit als separaten, späten Test-Schritt vor dem Launch zu behandeln.
Wo sich dieser Beitrag von unserem anderen Barrierefreiheits-Content unterscheidet
Wir haben Barrierefreiheit schon aus einer plattformspezifischen Perspektive behandelt: Magento 2 und das deutsche BFSG zeigt, warum bei Magento-Shops speziell die Theme-Ebene das Problem ist und was ein entkoppelter Frontend für genau diesen Stack ändert. Dieser Beitrag ist bewusst plattform-agnostisch: Der rechtliche Rahmen ist unabhängig vom Backend derselbe, und die technische Antwort, Konformität ins Komponenten-Kontrakt statt ins Audit zu verlagern, gilt egal ob ihr Magento, Shopware, commercetools oder einen Custom-Stack betreibt. Wenn ihr den Magento-Beitrag schon kennt, ist dieser Beitrag die allgemeine Version desselben Arguments, für Entwicklerinnen und Entwickler, die außerhalb einer einzelnen Plattform arbeiten.
Unsere Einschätzung
Ein Audit durchzuführen ist nicht falsch. Ein sauberer Ausgangsbefund zählt weiterhin, und Gerichte wie Marktüberwachungsbehörden werden weiterhin einen verlangen. Aber ein Audit beschreibt einen Zustand, es hält ihn nicht aufrecht. Konformität hält über die Zeit nur dort, wo sie eine Eigenschaft des Bausteins ist, den ihr auf jeder Seite wiederverwendet, der Komponente, nicht eine Eigenschaft der Seite selbst. Das ist eine technische Entscheidung, keine juristische, und euer Team kann sie treffen, bevor das nächste Audit dieselbe Fehlerklasse erneut findet. Wer diese Entscheidung heute trifft, spart sich in einem Jahr nicht das nächste Audit, aber die immer gleiche Überraschung darin.
Häufig gestellte Fragen
Ersetzt das die Notwendigkeit eines Barrierefreiheits-Audits? Nein. Ein initiales Audit legt weiterhin euren Ausgangszustand fest und wird von Marktüberwachungsbehörden und Gerichten oft als Nachweis ernsthaften Bemühens erwartet. Was sich ändert, ist das Danach: Statt bei jedem Release ein vollständiges Audit neu durchzuführen, prüft ihr einzelne Komponenten, bevor sie ausgeliefert werden.
Garantiert WCAG 2.1 AA rechtliche Konformität mit dem EAA oder BFSG? Der EN 301 549 zu folgen, die WCAG 2.1 AA vollständig übernimmt, ist der anerkannte Weg, Konformität für die meisten betroffenen digitalen Produkte und Dienstleistungen nachzuweisen. Ob euer konkretes Angebot im Anwendungsbereich liegt und ob eine Ausnahme greift, ist eine Rechtsfrage, die eure Rechtsberatung bestätigen sollte, nicht dieser Artikel.
Muss ich meinen Frontend neu aufbauen, um ein Komponenten-Kontrakt einzuführen? Nein. Der erste Schritt ist, das Kontrakt für die Komponenten festzuhalten, die ihr bereits habt, und neue Komponenten dagegen zu prüfen. Bestehende Seiten könnt ihr schrittweise ins Kontrakt überführen, sobald sie ohnehin angefasst werden, statt über ein Big-Bang-Rebuild.
Bedeutet die Kleinstunternehmen-Ausnahme, dass kleine Onlineshops das ignorieren können? Die Ausnahme im EAA ist eng gefasst: Sie erfasst dienstleistungsbezogene Pflichten für Unternehmen unter 10 Beschäftigten mit Umsatz oder Bilanzsumme unter 2 Millionen Euro, nicht Produktpflichten im Allgemeinen. Die meisten Händler mit einem relevanten Onlineshop sollten nicht ohne Prüfung mit ihrer Rechtsberatung davon ausgehen, dass sie darunter fallen.
Nächste Schritte
Wenn ihr sehen wollt, wie ein barrierefreies Komponenten-Kontrakt gegen euren aktuellen Frontend aussieht, bucht ein kostenloses 30-Minuten-Gespräch, und wir gehen gemeinsam durch, welche eurer Komponenten es bereits erfüllen, welche nicht, und was ein realistischer erster Schritt für euer Team wäre.
Mehr von der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und beschäftigt sich damit, wie Teams ihren Storefront gleichzeitig konform und schnell weiterentwickelbar halten, ohne Barrierefreiheit als wiederkehrenden Notfall zu behandeln.