Der European Accessibility Act ist jetzt durchsetzbar: Was E-Commerce-Teams jetzt tun müssen
- 1.Was sich geändert hat und warum es jetzt zählt
- 2.Wer tatsächlich betroffen ist (und warum du wahrscheinlich dazugehörst)
- 3.Was „zugänglich" praktisch für E-Commerce heißt
- 4.Der Business-Case jenseits von Compliance
- 5.Die technische Implementierungs-Roadmap
- 6.Warum Composable-Architektur Accessibility leichter macht
- 7.Häufige Fehler und wie du sie vermeidest
- 8.Die Enforcement-Landschaft: Echte Bußgelder, echte Konsequenzen
- 9.Compliance in deine Roadmap einbauen
- 10.Accessibility ist Strategie, keine Last
Es ist kein Vorschlag. Es ist kein zukünftiges Deadline. Die Durchsetzungs-Periode des European Accessibility Act (EAA) startete am 28. Juni 2025.
Wenn dein E-Commerce-Business an europäische Kundinnen verkauft und deine Website oder App nicht den WCAG-2.1-AA-Standards entspricht, bist du jetzt nicht konform. Bußgelder sind nicht theoretisch. In Deutschland reichen sie bis 500K Euro. In Frankreich 250K. Spanien setzt bis zu 300K durch. Selbst kleinere Märkte wie Irland verhängen 60K an Strafen.
Hier geht es nicht darum, freundlich zu Menschen mit Behinderungen zu sein. Das zählt natürlich. Aber Boards denken über Bußgelder, Haftungsrisiken und Wettbewerbsrisiko. Also spricht dieser Artikel ihre Sprache: was der EAA für E-Commerce-Operations tatsächlich bedeutet, wie die technische Umsetzung aussieht und warum das weniger Last ist, als du denkst, wenn du deine Plattform richtig architektiert hast.
Was sich geändert hat und warum es jetzt zählt
Der European Accessibility Act wurde 2019 publiziert. Alle wussten, dass er kommt. Über Jahre war er „irgendwann werden wir...", statt sofort darauf zu reagieren.
Der 28. Juni 2025 änderte das von einem aspirativen Zukunftszustand in eine Enforcement-Deadline.
Hier ist die Kern-Anforderung: Jede Website oder digitales Produkt, das EU-Markt-Kundinnen bedient, muss den WCAG-2.1-AA-Standards entsprechen. Punkt. Keine Mehrdeutigkeit. Keine Schonfrist.
WCAG 2.1 AA ist ein gut definierter Standard. Er ist nicht vage. Er umfasst Tastaturnavigation, Screen-Reader-Support, Farbkontrast-Werte, Form-Labeling, Video-Captions und Dutzende anderer spezifischer technischer Anforderungen. Entweder erfüllst du sie oder nicht.
Die Bußgelder sind hoch genug, dass das jetzt ein Compliance-Thema auf Board-Ebene ist, kein „Nice-to-have"-Feature.
Aber das Entscheidende: Der EAA gilt für jedes Business, das digitale Produkte oder Services in den EU-Markt verkauft, egal wo dein Unternehmen sitzt. Ein US-E-Commerce-Unternehmen, das an europäische Kundinnen verkauft, unterliegt EAA-Enforcement. Ein UK-Unternehmen, das in die EU verkauft, unterliegt. Ein australisches Unternehmen mit europäischen Kundinnen unterliegt.
Wenn dein europäischer Umsatz einen signifikanten Teil deines Business ausmacht (was bei den meisten globalen E-Commerce-Unternehmen so ist), ist das eine harte Anforderung, keine Option.
Wer tatsächlich betroffen ist (und warum du wahrscheinlich dazugehörst)
Konkret, wer unter EAA-Enforcement fällt:
Die Regulierung gilt für:
- E-Commerce-Websites, die EU-Kundinnen bedienen
- Mobile Applications, die in EU-App-Stores verfügbar sind
- Digitale Services mit physischen Gütern (deine Storefront) oder digitalen Gütern (Subscriptions, Downloads)
- B2C- und B2B-Digitale-Services
Es gibt enge Ausnahmen für Microenterprises (weniger als 10 Mitarbeitende und Jahresumsatz unter 2 Millionen Euro), aber diese Ausnahmen werden ausgephased. Bis 2030 sind praktisch alle Organisationen im Scope.
Wenn dein E-Commerce-Business in irgendeinem signifikanten Maßstab in europäischen Märkten operiert, bist du betroffen. Punkt.
Die geografische Frage ist oft, wo Verwirrung aufkommt. Dein Unternehmen kann in Kalifornien sitzen. Deine Server können in den USA gehostet sein. Aber wenn du auf deiner Website an EU-Kundinnen verkaufst, unterliegst du EAA-Enforcement. Die Regulierung folgt dem Markt, nicht dem Unternehmenssitz.
Was „zugänglich" praktisch für E-Commerce heißt
WCAG 2.1 AA ist ein detaillierter technischer Standard mit spezifischen, messbaren Anforderungen. Zu verstehen, wie Compliance konkret aussieht, zählt, weil es bestimmt, welche Arbeit auf dich zukommt.
Tastaturnavigation
Nutzerinnen sollten deinen kompletten E-Commerce-Flow nur mit Tastatur navigieren können. Keine Maus nötig. Das umfasst Produkt-Browsing, In-den-Warenkorb-Legen, Checkout, Form-Completion und Payment.
Aktueller Stand: Viele E-Commerce-Seiten haben Tastaturnavigations-Löcher. Modal-Windows, die Fokus einschließen. Dropdown-Menüs, die unerwartet schließen, wenn eine Tastatur-Nutzerin navigiert. Buttons, die nicht tastatur-zugänglich sind.
Erforderlicher Stand: Jedes interaktive Element ist per Tastatur erreichbar. Tab-Reihenfolge ist logisch. Es gibt einen sichtbaren Focus-Indikator. Tastatur-Nutzerinnen navigieren den Checkout ohne Sackgassen.
Screen-Reader-Support
Nutzerinnen mit Sehbeeinträchtigung verlassen sich auf Screen-Reader (Software, die Seiteninhalte vorliest). Deine Seite muss so strukturiert sein, dass Screen-Reader alle Inhalte richtig interpretieren, inklusive Produktinformation, Preise, Form-Fields und Checkout-Steps.
Aktueller Stand: Viele E-Commerce-Seiten haben Screen-Reader-Probleme, weil das zugrundeliegende HTML schlecht strukturiert ist. Forms haben keine Labels. Produktinformation steckt in Bildern ohne Alt-Text. Komplexe Layouts nutzen CSS, um visuelle Beziehungen zu schaffen, die Screen-Reader nicht erkennen.
Erforderlicher Stand: Alle interaktiven Elemente haben klare Labels. Form-Fields sind korrekt mit ihren Labels verknüpft. Produktinformation ist als Text verfügbar, nicht nur als Bild. Komplexe Layouts sind semantisch ausgezeichnet. Navigations-Struktur ist Screen-Readern klar.
Farbkontrast
Text muss ausreichenden Kontrast zum Hintergrund haben. Die Anforderung: 4,5:1 für normalen Text, 3:1 für großen Text.
Aktueller Stand: Trendy Design kollidiert manchmal mit Kontrast-Anforderungen. Hellgrauer Text auf weißem Hintergrund sieht gut aus. Er fällt durch die Accessibility.
Erforderlicher Stand: Aller Text erfüllt Kontrast-Minimums. Das beinhaltet Paragraph-Text, Button-Labels, Form-Placeholder und Error-Messages.
Form-Accessibility
Forms sind eine kritische E-Commerce-Komponente. WCAG AA verlangt korrektes Labeling, klares Error-Messaging und zugängliche Form-Controls.
Aktueller Stand: Viele E-Commerce-Forms haben keine Labels. Validierungs-Fehler erscheinen, zeigen aber nicht klar, welches Feld problematisch ist. Pflichtfelder sind nicht markiert. Placeholder-Text maskiert sich als Label.
Erforderlicher Stand: Jedes Form-Field hat ein explizites, verknüpftes Label. Pflichtfelder sind markiert. Error-Messages identifizieren klar, welches Feld problematisch ist und was der Fehler ist. Passwort-Anforderungen werden klar kommuniziert.
Video und Multimedia
Wenn deine E-Commerce-Site Produkt-Videos beinhaltet (üblich bei Apparel, Elektronik, Beauty), müssen sie Captions und Transkripte enthalten.
Erforderlicher Stand: Jedes Produkt-Video hat Captions. Audio-Descriptions werden für visuelle Inhalte geliefert, die aus Captions allein nicht ersichtlich sind.
Heading-Struktur und Content-Organisation
Seitenstruktur muss logisch sein und über saubere Heading-Hierarchie transportiert werden, nicht nur über visuelles Styling.
Erforderlicher Stand: Seiten nutzen H1, H2, H3 Headings in logischer Reihenfolge. Navigations-Struktur ist klar. Content-Sections sind sauber organisiert.
Der Business-Case jenseits von Compliance
Die meisten E-Commerce-Teams fokussieren auf „wir müssen konform sein, um Bußgelder zu vermeiden". Das ist nötig, aber unvollständig. Es gibt einen echten Business-Upside zur Accessibility.
Marktgröße
Ungefähr 80 Millionen Menschen in der EU haben irgendeine Form von Behinderung. Das ist keine Nische. Das ist ein substanzielles Marktsegment. Wenn du deine E-Commerce-Site zugänglich machst, vermeidest du nicht nur Bußgelder. Du öffnest deine Site einer größeren Customer-Base.
Manche dieser 80 Millionen haben permanente Behinderungen. Viele haben temporäre Behinderungen (gebrochener Arm, Recovery nach OP) oder situative Behinderungen (Versuch, deine Site auf einem Mobilphone in heller Sonne zu navigieren, was Farbkontrast kritisch macht).
Accessibility-Verbesserungen erreichen über die Disability-Community hinaus. Sie verbessern die Experience für alle.
SEO-Vorteile
Suchmaschinen indizieren E-Commerce-Sites ähnlich, wie Screen-Reader sie interpretieren. Sauber gelabelte Forms, semantisches HTML, beschreibender Link-Text und klare Struktur nützen SEO und Accessibility gleichermaßen.
Die technischen Verbesserungen, die du für Accessibility machst, verbessern oft Such-Sichtbarkeit. Das ist kein Nebeneffekt. Das ist ein echtes, messbares Business-Outcome.
UX- und Conversion-Verbesserung
Vereinfachte Forms, klarere Error-Messages, verbesserte Navigation und besserer Kontrast helfen nicht nur Menschen mit Behinderungen. Sie verbessern Conversion für alle.
Accessibility offenbart oft UX-Probleme, die alle Nutzer treffen. Wenn du diese Probleme fixt, siehst du meist messbare Verbesserungen in Conversion-Raten, besonders auf Mobile.
Wettbewerbs-Positionierung
Wettbewerber, die warten, bis Enforcement-Druck Action erzwingt, werden hektisch. Unternehmen, die Accessibility proaktiv adressieren, ihre Compliance dokumentieren und sie als Marketing-Differenzierer nutzen, positionieren sich besser am Markt.
Early-Mover können sagen: „Wir sind EAA-konform. Wir sind stolz darauf. Wir designen für alle." Das ist ein Wettbewerbsvorteil, nicht nur eine Compliance-Checkbox.
Die technische Implementierungs-Roadmap
Die praktische Sequenz zur EAA-Compliance:
Phase 1: Audit (4-6 Wochen)
Fahre ein Accessibility-Audit deiner aktuellen E-Commerce-Site. Das kann automatisiert (Tools wie Axe, WAVE oder Lighthouse geben dir eine Baseline) oder manuell sein (Arbeit mit Accessibility-Spezialisten, um Screen-Reader-Kompatibilität, Tastaturnavigation usw. zu testen).
Das Audit offenbart zwei Issue-Typen:
- Easy Fixes: Farbkontrast-Probleme, fehlende Alt-Texte auf Bildern, falsch gelabelte Form-Fields. Üblich 40-50 Prozent der Issues.
- Strukturelle Issues: Tastaturnavigations-Probleme, Screen-Reader-Inkompatibilität durch schlechte HTML-Struktur, komplexe Layouts, die mit Assistive Technology nicht funktionieren. Die brauchen mehr Arbeit.
Budget: 10.000 bis 30.000 US-Dollar abhängig von Site-Komplexität und ob du externe Auditoren engagierst.
Phase 2: Priorisieren
Nicht alle Accessibility-Issues sind für E-Commerce gleich wichtig. Priorisiere nach Impact und Aufwand:
1. Critical-Path-Issues: Checkout-Accessibility, Produkt-Browsing, Form-Navigation. Wenn Leute keinen Kauf abschließen können, ist Accessibility irrelevant. 2. High-Impact-Fixes: Farbkontrast (easy), Alt-Text (medium), Heading-Struktur (medium). 3. Lower-Impact-Issues: Dekoratives Element-Labeling, fortgeschrittene Keyboard-Shortcuts.
Phase 3: Umsetzen
Starte mit den priorisierten Issues. Die meisten verlangen:
- HTML-Fixes (korrektes Labeling, semantische Struktur)
- CSS-Updates (Kontrast-Werte, Focus-States)
- JavaScript-Justierungen (Keyboard-Event-Handling, ARIA-Attribute)
Die Implementierungs-Timeline hängt von deiner Architektur ab. Wenn deine Site auf einer Composable-Plattform wie Laioutr mit zugänglichen Komponenten in der UI-Library gebaut ist, sind Accessibility-Fixes meist schneller. Wenn deine Site ein monolithischer Custom-Build ist, dauert die Umsetzung länger.
Budget: 50.000 bis 150.000 US-Dollar abhängig von aktuellem Stand und Site-Komplexität.
Phase 4: Testing
Automatisiertes Testing fängt etwa 30 Prozent der Accessibility-Issues. Manuelles Testing fängt den Rest.
Testing sollte enthalten:
- Keyboard-only Navigation des vollen E-Commerce-Flows
- Screen-Reader-Testing (NVDA auf Windows, JAWS, VoiceOver auf Mac)
- Mobile Accessibility (Touch-Navigation, Mobile-Screen-Reader)
- Farbkontrast-Verifizierung über die Site
Budget: 15.000 bis 40.000 US-Dollar für externes Accessibility-Testing und Verifizierung.
Phase 5: Dokumentation
Erstelle und pflege Dokumentation deiner Accessibility-Bemühungen. Welche Standards du erfüllst. Welche Bereiche getestet wurden. Bekannte Issues mit geplanter Remediation.
Diese Dokumentation ist wertvoll, falls du je Enforcement-Action gegenüberstehst. Sie zeigt Good-Faith-Aufwand zur Compliance.
Budget: Minimal intern; 5.000 bis 10.000 US-Dollar für externe Verifizierung.
Warum Composable-Architektur Accessibility leichter macht
Hier zählt Plattform-Architektur.
Monolithische E-Commerce-Plattformen, vor 15+ Jahren gebaut, waren nicht mit Accessibility als Kernprinzip designt. Accessibility in eine monolithische Codebase nachzurüsten, ist teuer, weil du die zugrundeliegende Architektur ändern, alles Downstream testen und Seiteneffekte übers ganze System managen musst.
Composable-Architektur, gebaut auf Best-of-Breed-Komponenten, macht Accessibility-Implementierung und -Pflege schneller.
Warum? Weil:
1. Zugängliche Komponenten sind wiederverwendbar: Eine korrekt zugängliche Button-Komponente, ein Form-Field oder ein Navigations-Menü lässt sich über deine ganze E-Commerce-Site nutzen. Du fixst Accessibility einmal in der Component-Library. Sie ist überall gefixt.
1. Klare Separation of Concerns: Mit Composable-Architektur auditest und fixst du Accessibility in jeder Komponente unabhängig. Wenn die Button-Komponente deines Laioutr-Storefronts zugänglich ist, ist jeder Button über alle E-Commerce-Experiences zugänglich.
1. Vendor-Verantwortung: Wenn du Komponenten von Vendoren nutzt, die zu Accessibility committed sind (wie Laioutrs WCAG-3.0-Ready-Komponenten), startest du nicht bei null. Der Vendor hat in Accessibility investiert. Du erbst diese Arbeit.
1. Einfacheres Testing: Composable-Plattformen liefern oft sauberere Testing-Infrastruktur. Zugängliche Komponenten sind programmatisch leichter zu testen, weil sie Standards folgen. Das heißt effizienteres automatisiertes Testing, weniger manuelle Test-Zyklen.
Wenn du eine neue E-Commerce-Plattform baust oder eine bestehende für EAA-Compliance modernisierst, ist ein Composable-Ansatz signifikant effizienter, als Accessibility in einen Legacy-Monolithen nachzurüsten.
Häufige Fehler und wie du sie vermeidest
Fehler 1: Accessibility als einmaliges Projekt behandeln
Accessibility ist keine Checkbox. Es ist ein laufendes Commitment. Neue Features, Design-Änderungen und Third-Party-Integrationen können Accessibility-Regressionen einführen.
Vermeide das, indem du: Accessibility-Testing in deinen Entwicklungs-Prozess baust. Accessibility-Review als Teil des Code-Reviews verlangst. Accessibility in deinen QA-Prozess einbeziehst, nicht als Nachgedanke.
Fehler 2: Nur auf automatisiertes Testing verlassen
Automatisierte Tools fangen etwa 30 Prozent der Accessibility-Issues. Die anderen 70 Prozent verlangen manuelles Testing mit echter Assistive Technology.
Vermeide das, indem du: Automatisiertes Testing (schnell und günstig) mit regelmäßigem manuellem Testing (langsamer, aber fängt echte Issues) kombinierst. Plane mindestens quartalsweise manuelles Accessibility-Testing.
Fehler 3: Annehmen, Accessibility heißt nur Screen-Reader
Accessibility deckt viele Behinderungen ab: Sehbeeinträchtigung, motorische Beeinträchtigung, kognitive Behinderungen, Hörbeeinträchtigung. Screen-Reader-Testing ist wichtig, aber nicht das ganze Bild.
Vermeide das, indem du: Mit mehreren Assistive Technologies testest. Keyboard-only-Navigation (für motorische Beeinträchtigung) testest. Farbkontrast (für Farbenblindheit) testest. Heading-Struktur (für kognitive Accessibility) testest. Video-Captions (für Hörbeeinträchtigung) testest.
Fehler 4: Keine Behinderten in Tests einbeziehen
Der beste Weg, Accessibility-Issues zu fangen, ist mit echten Nutzerinnen zu testen, die auf Assistive Technology angewiesen sind.
Vermeide das, indem du: Behinderte Nutzerinnen in dein Accessibility-Testing einbeziehst. User-Feedback offenbart oft Issues, die selbst erfahrene Auditoren übersehen.
Fehler 5: Third-Party-Integrationen ignorieren
Deine E-Commerce-Site integriert wahrscheinlich Payment-Provider, Review-Plattformen, Analytics-Tools und andere Third-Parties. Wenn diese Integrationen nicht zugänglich sind, ist deine Site nicht vollständig zugänglich.
Vermeide das, indem du: Third-Party-Integrationen auf Accessibility auditest. Vendoren wählst, die Accessibility unterstützen. Deine Integrationen so baust, dass sie Accessibility-Standards halten, auch wenn Third-Party-Tools nicht perfekt zugänglich sind.
Die Enforcement-Landschaft: Echte Bußgelder, echte Konsequenzen
Du fragst dich vielleicht: Werden diese Bußgelder tatsächlich durchgesetzt? Ja.
Die Enforcement-Agenturen variieren nach Land, aber sie sind real:
- Deutschland: Maximum-Bußgeld 500.000 Euro (Bundeskartellamt setzt durch)
- Frankreich: Bis zu 250.000 Euro (CNIL setzt durch)
- Spanien: Bis zu 300.000 Euro (verschiedene Regional-Authorities)
- Italien: Bis zu 50.000 Euro pro Verstoß
- Niederlande: Bis zu 4,3 Millionen Euro oder 4 Prozent des Jahresumsatzes
- Irland: Bis zu 60.000 Euro
Mehrere EU-Mitgliedsstaaten haben bereits Warnungen oder Bußgelder gegen nicht-konforme Websites ausgesprochen. Das ist nicht spekulativ. Enforcement passiert jetzt.
Der Enforcement-Fokus startete mit großen Plattformen und Hochtraffic-Sites, expandiert aber. Wenn dein E-Commerce-Business in signifikantem Maßstab in Europa operiert, wirst du irgendwann auditiert.
Compliance in deine Roadmap einbauen
Wenn deine E-Commerce-Site noch nicht EAA-konform ist, muss das jetzt auf deine Roadmap.
Eine vernünftige Timeline für die meisten Sites:
- Monate 1-2: Accessibility-Audit und Priorisierung
- Monate 2-4: Umsetzung priorisierter Fixes
- Monate 4-5: Testing und Remediation
- Monat 6: Compliance-Verifizierung und Dokumentation
Das ist eine Sechs-Monats-Timeline für die meisten E-Commerce-Sites vom Audit zur Compliance. Manche werden schneller (wenn du mit moderner, gut strukturierter Codebase startest). Andere langsamer (wenn du Accessibility in Legacy-Systeme nachrüstest).
Starte jetzt. Auf Enforcement-Druck zu warten, wird teurer und stressiger als proaktive Planung.
Accessibility ist Strategie, keine Last
Die Erzählung rund um EAA-Compliance im E-Commerce war oft „Compliance-Last". Noch eine Regulierung. Noch eine Anforderung. Noch eine Kostenposition.
Reframe das: Accessibility ist Strategie.
Wenn du deine E-Commerce-Site zugänglich machst, erweiterst du deinen adressierbaren Markt um 80M+ potenzielle Kundinnen in Europa. Du verbesserst UX für alle. Du verbesserst SEO. Du reduzierst Legal-Risiko. Du signalisierst Kundinnen, dass deine Brand Inklusion wertschätzt.
Das sind keine Compliance-Nebeneffekte. Das sind echte Business-Vorteile.
Die technische Arbeit ist real und verlangt Investition. Aber sie ist kein unmöglicher Lift, besonders wenn du richtig architektiert bist.
Starte dein Audit. Priorisiere deine Umsetzung. Bau Accessibility in deinen Entwicklungs-Prozess. Dokumentiere deine Compliance.
So bewegst du dich von „oh nein, noch eine Regulierung" zu „so machen wir Business".
Bereit, deine E-Commerce-Site zugänglich zu machen?
Wenn du Plattformen evaluierst oder deine E-Commerce-Architektur modernisierst, sollte Accessibility ein Kern-Entscheidungs-Kriterium sein. Laioutrs Storefront und UI-Library sind mit WCAG-2.1-AA-Compliance als Fundamental-Prinzip gebaut. Unsere Komponenten sind zugänglich by Design, nicht durch Nachrüstung.
Schau dir unsere WCAG-Ready-Plattform an, schau die zugänglichen UI-Komponenten oder tauche ein, wie Composable-Architektur Accessibility-Implementierung schneller macht.
EAA-Compliance ist jetzt Realität. Mach sie zum strategischen Vorteil, keine Last.
Mehr von der Laioutr-Plattform
Mehr dazu: European Accessibility Act 2025: Was sich ändert und was es für Ecommerce-Enterprises bedeutet und EAA + HCL Commerce+: Warum Backend-Compliance allein nicht reicht.