E-Commerce-Barrierefreiheit: So machen Sie Ihren Online-Shop WCAG-konform

Stellen Sie sich vor, Sie verbringen zehn Minuten damit, online ein Geburtstagsgeschenk zu kaufen – nur um dann an einem Dropdown-Menü hängen zu bleiben, das Ihr Screenreader nicht auslesen kann, oder an einem Checkout-Formular, das den Tastaturfokus einfängt und nicht mehr freigibt. Für die geschätzten 61 Millionen Erwachsenen mit Behinderungen in den Vereinigten Staaten ist das kein hypothetischer Fall. Es ist tägliche Realität. Und für Online-Händler übersetzt sich das direkt in entgangene Umsätze: Untersuchungen legen nahe, dass $2.3 billion in annual online revenue aufgrund unzugänglicher Checkout-Flows verloren gehen, während 71% der Nutzer mit Behinderungen unzugängliche E‑Commerce‑Sites sofort verlassen, statt sich hindurchzukämpfen.

Warum Barrierefreiheit im E‑Commerce nicht mehr optional ist

Die rechtlichen und finanziellen Risiken rund um Web-Barrierefreiheit waren noch nie höher, und E‑Commerce steht dabei im direkten Fokus. Allein im Jahr 2024 wurden 4,605 ADA-Website-Klagen vor US-Bundesgerichten eingereicht, wobei der E‑Commerce-Sektor den Löwenanteil trug – je nach Quelle entfielen etwa 68–77% aller Klagen auf diesen Bereich. Der Trend beschleunigt sich: In der ersten Hälfte des Jahres 2025 wurden 2,014 Klagen wegen digitaler Barrierefreiheit eingereicht, ein Anstieg um 37% gegenüber dem gleichen Zeitraum 2024, womit der Sektor auf Kurs ist, bis Jahresende mehr als 4,975 Klagen zu verzeichnen.

Auch Vergleiche sind alles andere als trivial. Übliche Einigungen liegen zwischen $25,000 und $75,000, zuzüglich Anwaltskosten auf beiden Seiten und den Kosten für die Nachbesserungen, die Sie eigentlich von Anfang an hätten durchführen sollen. Noch ernüchternder: 2024 wurde fast die Hälfte aller Fälle gegen Unternehmen eingereicht, die bereits zuvor verklagt worden waren und ihre Websites nicht umfassend behoben hatten. Ein einmaliger Vergleich schützt Sie nicht vor der nächsten Klage, wenn der zugrunde liegende Code weiterhin fehlerhaft ist.

Auch weltweit verschärft sich die Regulierung. Der European Accessibility Act (EAA) ist seit dem 28. Juni 2025 durchsetzbar und gilt für E‑Commerce-Plattformen, die in EU-Märkte verkaufen – mit Strafen von bis zu €100,000 oder 4% des Jahresumsatzes in einigen Mitgliedstaaten. In den Vereinigten Staaten hat das Department of Justice im April 2024 eine endgültige Regel veröffentlicht, die WCAG 2.1 Level AA formell für Websites von staatlichen und kommunalen Behörden vorschreibt, und obwohl private Unternehmen noch keinen verbindlichen bundesweiten technischen Standard haben, nutzen Gerichte und das DOJ WCAG konsequent als faktischen Maßstab bei der Bewertung von ADA-Ansprüchen. Die Dynamik ist unübersehbar: Auf klarere Vorschriften zu warten, ist eine Hochrisikostrategie.

Jenseits des Rechtsrisikos steht ein riesiger, unterversorgter Markt auf dem Spiel. Menschen mit Behinderungen und ihre Familien stehen Schätzungen zufolge für $13 trillion an globaler wirtschaftlicher Aktivität, und das verfügbare Einkommen der weltweiten Community von Menschen mit Behinderungen allein wird auf jährlich $1.9 trillion geschätzt. Marken, die Barrierefreiheit priorisieren, sehen zudem messbare Loyalitätsvorteile – eine Studie fand eine um 18% höhere Kundenbindungsrate unter Verbraucherinnen und Verbrauchern mit Behinderungen, die sich gut bedient fühlten. Barrierefreiheit ist keine Wohltätigkeit. Sie ist gutes Geschäft.

WCAG verstehen: Der Standard, der wirklich zählt

Die Web Content Accessibility Guidelines (WCAG), entwickelt vom World Wide Web Consortium (W3C), sind der international anerkannte technische Rahmen für digitale Barrierefreiheit. Sie sind um vier Kernprinzipien organisiert – bekannt unter dem Akronym POUR: Inhalte müssen Perceivable (wahrnehmbar), Operable (bedienbar), Understandable (verständlich) und Robust (robust) sein. Jedes Prinzip gliedert sich in spezifische, testbare Erfolgskriterien.

Die aktuelle Version, WCAG 2.2, wurde im Oktober 2023 veröffentlicht und fügt der vorherigen Version neun neue Erfolgskriterien hinzu, bleibt dabei aber vollständig abwärtskompatibel. Wer WCAG 2.2 erfüllt, erfüllt automatisch auch WCAG 2.1 und 2.0. Für die meisten E‑Commerce-Unternehmen sollte das Ziel Konformität auf Level AA sein – es ist der Standard, auf den sich praktisch jeder regulatorische Rahmen bezieht, der Maßstab, auf den Gerichte in ADA-Verfahren schauen, und das Niveau, das die größte Bandbreite an Nutzerinnen und Nutzern sinnvoll bedient. Level A ist das absolute Minimum, und Level AAA ist zwar erstrebenswert, aber für die meisten komplexen transaktionalen Sites praktisch nicht erreichbar.

Die neun neuen Kriterien von WCAG 2.2 haben mehrere Anforderungen eingeführt, die direkte, hochrelevante Auswirkungen auf den Online-Handel haben: Mindestgrößen für Touch-Ziele (2.5.8), Fokusindikatoren, die nicht von Sticky-Headern verdeckt werden (2.4.11), Vermeidung redundanter Eingaben in mehrstufigen Checkout-Flows (3.3.7), zugängliche Authentifizierung, die nicht auf kognitiven Rätseln wie komplexen CAPTCHAs beruht (3.3.8), und konsistente Platzierung von Hilfemechanismen über Seiten hinweg (3.2.6). Das sind keine abstrakten Richtlinien – sie entsprechen direkt den Reibungspunkten, die dazu führen, dass Ihre Kundschaft Warenkörbe abbricht.

Die häufigsten Barrierefreiheitsfehler auf E‑Commerce-Sites

Forschungen zeigen immer wieder, dass E‑Commerce-Sites bei einem vorhersehbaren Set von Problemen scheitern. Diese Fehlermuster zu verstehen, ist der erste Schritt, um Ihre Nachbesserungsarbeit zu priorisieren. Laut dem WebAIM Million Report 2026 bleibt Text mit zu geringem Kontrast das am weitesten verbreitete Problem und findet sich inzwischen auf 83.9% der Startseiten – gegenüber 79.1% im Jahr davor. Die durchschnittliche Startseite enthält jetzt 34 unterschiedliche Instanzen von Text mit zu geringem Kontrast. Das bedeutet: Ihr Sale-Banner, Ihre Button-Beschriftungen, Ihre Preisschilder – es ist sehr wahrscheinlich, dass ein erheblicher Teil Ihrer Kundschaft mit eingeschränktem Sehvermögen sie schlicht nicht lesen kann.

Über den Kontrast hinaus fand das Baymard Institute, dass unter 33 umsatzstarken E‑Commerce-Sites, die gegen WCAG 2.1 AA bewertet wurden: 82% Barrierefreiheitsprobleme bei Produktbildern hatten, 73% Probleme mit Links, 64% Probleme mit Tastaturnavigation und 58% Probleme mit der Auszeichnung von Formularfeldern. Das sind keine Randfälle – es sind grundlegende Komponenten der User Journey jedes Online-Shops, vom Stöbern bis zum Kauf.

Hier sind die Fehlerkategorien, die in Audits und ADA-Klagen gegen Online-Shops am häufigsten auftauchen:

• Fehlender oder minderwertiger Alt-Text bei Produktbildern: Screenreader geben den Dateinamen des Bildes aus oder überspringen es vollständig, wenn kein Alt-Text vorhanden ist. Guter Alt-Text beschreibt, was das Bild tatsächlich zeigt – nicht nur „Produktbild“, sondern etwa „Navyblauer Merino-Wollpullover mit Rundhalsausschnitt, flach auf weißem Hintergrund liegend“.
• Unzugängliche Formularbeschriftungen und Fehlermeldungen: Jedes Eingabefeld in Ihrem Checkout muss ein programmatisch verknüpftes <label>-Element haben. Fehlermeldungen, die nur als roter Text erscheinen – ohne textliche Beschreibung – sind für Screenreader-Nutzer unsichtbar und verstoßen gegen Kriterien zur Farbverwendung.
• Tastaturfallen in Modals und Drawern: Warenkorb-Overlays, Größenauswahlen und Gutschein-Modals, die den Tastaturfokus abfangen, aber der Nutzerin oder dem Nutzer nicht erlauben, mit der Escape-Taste zu entkommen, sind ein häufiges und gravierendes Hindernis. Wer das Modal nicht verlassen kann, kann den Kauf nicht abschließen.
• Interaktive Elemente, die nicht per Tastatur bedienbar sind: Karussells, benutzerdefinierte Dropdowns, Mengenregler und Bild-Zoom-Steuerungen, die ohne ARIA-Rollen und Tastatur-Event-Handler gebaut wurden, existieren für reine Tastaturnutzer schlicht nicht.
• Dynamische Warenkorb-Updates, die Assistive Technology nicht angekündigt werden: Wenn eine Nutzerin oder ein Nutzer einen Artikel in den Warenkorb legt und sich die Warenkorbanzahl per JavaScript ohne Seitenneuladen ändert, bemerken Screenreader das nicht, sofern Sie es nicht explizit über eine ARIA-Live-Region ankündigen.
• Unzureichende Touch-Zielgrößen: WCAG 2.2 verlangt, dass interaktive Elemente mindestens 24×24 CSS-Pixel groß sind. Kleine „Zur Wunschliste hinzufügen“-Icons, Schließen-Buttons in Modals und Farbmuster-Swatches für Varianten verfehlen dies auf Mobilgeräten regelmäßig.
• Fokusindikatoren, die von Sticky-Headern oder überlappenden Inhalten verdeckt werden: Wenn eine Nutzerin oder ein Nutzer zu einem Link oder Button tabbt und der Fokusring unter einer persistenten Navigationsleiste oder einem Cookie-Banner verborgen ist, kann sie oder er nicht erkennen, wo sie oder er sich auf der Seite befindet.

Eine hilfreiche Faustregel: Wenn Sie Ihren gesamten Kaufprozess – von der Landingpage bis zur Bestellbestätigung – nicht ausschließlich mit der Tastatur und ohne Maus durchlaufen können, ist Ihr Checkout nicht barrierefrei.

Eine Seiten-für-Seite-Roadmap zur Barrierefreiheit für Ihren Shop

Barrierefreiheit im E‑Commerce ist nicht ein einziges Problem – es ist eine Sammlung spezifischer, kontextabhängiger Probleme, die je nach Seitentyp variieren. Der effektivste Ansatz zur Nachbesserung arbeitet die Customer Journey systematisch durch, beginnend mit den Bereichen mit der größten Wirkung.

Produktlisten-Seiten (PLPs): Stellen Sie sicher, dass Filtersteuerungen – Checkboxen, Slider, Dropdowns – per Tastatur bedienbar sind und sichtbare Fokuszustände haben. Wenn Filter die Ergebnisse dynamisch aktualisieren, umschließen Sie den Ergebnisbereich mit einer aria-live-Region, damit Screenreader ankündigen, dass sich die Produktliste geändert hat. Jeder Produktkarten-Link sollte beschreibenden Text haben (nicht nur „Ansehen“ oder „Mehr erfahren“), und Produktbilder benötigen aussagekräftigen Alt-Text.

Produktdetailseiten (PDPs): Variantenauswahlen (Größe, Farbe, Material) sind ein notorischer Schwachpunkt. Benutzerdefiniert gestaltete Radiobuttons oder Buttons, die als Toggle-Schalter verwendet werden, benötigen korrekte ARIA-Rollen und -Zustände. Wenn Sie eine Größentabelle in einem Modal verwenden, muss dieses Modal den Fokus korrekt verwalten – ihn im geöffneten Dialog halten und beim Schließen zum auslösenden Element zurückgeben. Produktvideos müssen Untertitel haben; Audiodeskriptionen sind erforderlich, wenn relevante visuelle Informationen ohne Sprechertext vermittelt werden.

Einkaufswagen und Mini-Warenkorb: Wenn eine Nutzerin oder ein Nutzer einen Artikel in den Warenkorb legt, sollte die Bestätigung über eine aria-live-Region mit role='status' oder role='alert' für Screenreader angekündigt werden. Mengensteuerungen sollten per Tastatur bedienbar sein, und der „Artikel entfernen“-Button muss für jede Position im Warenkorb einen eindeutigen, beschreibenden zugänglichen Namen haben – nicht einfach viermal „Entfernen“ für vier verschiedene Produkte.

Checkout-Flow: Hier liegen die gravierendsten WCAG-Verstöße – und hier entstehen die teuersten Klagen. Nach dem Konformitätsmodell von WCAG muss jede Seite in einem Prozess konform sein – Sie können keine barrierefreie Produktseite und eine unzugängliche Zahlungsseite haben und dennoch Konformität beanspruchen. Zentrale Anforderungen sind: Alle Formulareingaben müssen dauerhaft sichtbare Beschriftungen haben (nicht nur Platzhaltertext, der verschwindet, sobald die Nutzerin oder der Nutzer zu tippen beginnt), Fehlermeldungen müssen das konkrete Feld identifizieren und in Textform beschreiben, was schiefgelaufen ist, Autocomplete-Attribute (autocomplete='email', autocomplete='cc-number' usw.) müssen vorhanden sein, um Nutzerinnen und Nutzern mit kognitiven und motorischen Beeinträchtigungen zu helfen, und der gesamte Flow muss ohne Maus durchführbar sein. WCAG 2.2 verbietet außerdem, dass Nutzerinnen und Nutzer Informationen erneut eingeben müssen, die sie in derselben Sitzung bereits bereitgestellt haben – wenn Ihr Checkout also nach der Rechnungsadresse fragt, nachdem die Kundin oder der Kunde gerade die Lieferadresse eingegeben hat, sollte diese Information automatisch übernehmbar sein.

Account-Login und Registrierung: Das Kriterium „Accessible Authentication“ (3.3.8) in WCAG 2.2 bedeutet, dass Sie Nutzerinnen und Nutzer nicht verpflichten dürfen, einen kognitiven Funktionstest – wie ein Standard-Bild-CAPTCHA – als einzige Authentifizierungsmethode zu lösen. Bieten Sie Alternativen wie Magic Links per E‑Mail, SMS-Codes oder Third-Party-OAuth an. Wenn Sie CAPTCHA verwenden, ist eine Audio-Alternative das Minimum, aber Befürworter kognitiver Barrierefreiheit empfehlen, ganz von CAPTCHA wegzugehen und weniger belastende Methoden zu nutzen.

Implementierung auf Code-Ebene: Wie barrierefreier E‑Commerce tatsächlich aussieht

Barrierefreiheit ist letztlich ein Codeproblem, und abstrakte Hinweise reichen nur begrenzt. So sieht eine korrekte Implementierung für einige der gängigsten E‑Commerce-Muster aus.

Für einen Skip-Navigation-Link (essenziell für Tastaturnutzer, die nicht auf jeder Seite durch Ihren gesamten Header tabben wollen):

<a href='#main-content' class='skip-link'>Skip to main content</a>

<style>
  .skip-link {
    position: absolute;
    top: -40px;
    left: 0;
    background: #000;
    color: #fff;
    padding: 8px 16px;
    z-index: 9999;
    text-decoration: none;
  }
  .skip-link:focus {
    top: 0;
  }
</style>

<main id='main-content' tabindex='-1'>
  <!-- your page content -->
</main>

Für eine Warenkorb-Update-Ankündigung, die Screenreader automatisch erfassen, wenn ein Artikel hinzugefügt wird:

<!-- Place this in your page HTML -->
<div
  role='status'
  aria-live='polite'
  aria-atomic='true'
  class='visually-hidden'
  id='cart-announcement'
></div>

<!-- Then in your JavaScript, after a cart update: -->
<script>
  function announceCartUpdate(message) {
    const region = document.getElementById('cart-announcement');
    region.textContent = '';
    // Force the browser to register the DOM change before updating
    requestAnimationFrame(() => {
      region.textContent = message;
    });
  }
  // Example usage:
  announceCartUpdate('Blue Linen Shirt added to cart. Cart now contains 3 items.');
</script>

Für einen WCAG-2.2-konformen Fokusindikator, der die Anforderungen an Kontrast und Größe erfüllt:

<style>
  /* Remove browser default and replace with a strong custom indicator */
  :focus-visible {
    outline: 3px solid #0057b8;
    outline-offset: 3px;
    border-radius: 2px;
  }
  /* Ensure sticky header doesn't obscure focused elements (WCAG 2.4.11) */
  :focus {
    scroll-margin-top: 80px; /* match your header height */
  }
</style>

Für korrekt verknüpfte Formularlabels und Inline-Fehlermeldungen im Checkout:

<div class='form-field'>
  <label for='email'>Email address <span aria-hidden='true'>*</span></label>
  <input
    type='email'
    id='email'
    name='email'
    autocomplete='email'
    aria-required='true'
    aria-describedby='email-error'
  />
  <span
    id='email-error'
    role='alert'
    class='error-message'
  ><!-- Populated by JS on validation failure --></span>
</div>

Testing: Automatisierte Tools sind ein Startpunkt, kein Ziel

Eines der gefährlichsten Missverständnisse in der Barrierefreiheits-Compliance ist, dass automatisierte Scanner Ihnen sagen können, ob Ihre Site barrierefrei ist. Das können sie nicht. Automatisierte Tools können etwa 30–40% der WCAG-Probleme erkennen – etwa fehlende Alt-Attribute, offensichtliche Kontrastfehler und fehlende Formularlabels. Die übrigen 60–70% der Probleme erfordern menschliches Urteil: Beschreibt dieser Alt-Text das Bild tatsächlich sinnvoll? Ist die Lesereihenfolge logisch, wenn sie per Screenreader durchlaufen wird? Ist die Fehlermeldung wirklich hilfreich, oder steht dort nur „ungültige Eingabe“?

Eine realistische Teststrategie für einen E‑Commerce-Shop nutzt mehrere Ebenen. Beginnen Sie mit einem automatisierten Scanner – Tools wie axe-core, WAVE oder Lighthouse – und führen Sie ihn für jedes Seitentemplate aus (PLP, PDP, Warenkorb, Checkout, Account). So identifizieren Sie schnell die „Low-Hanging Fruits“. Führen Sie dann eine Session nur mit der Tastatur durch: Ziehen Sie die Maus ab und versuchen Sie, einen vollständigen Kauf abzuschließen. Tabben Sie durch alles. Versuchen Sie, Modals zu öffnen und zu schließen. Versuchen Sie, eine Warenkorbmenge zu aktualisieren. Versuchen Sie, einen Gutscheincode anzuwenden. Wenn Sie irgendwo stecken bleiben, ist das ein Fehler.

Testen Sie anschließend mit mindestens einem Screenreader. NVDA mit Firefox und VoiceOver mit Safari sind für die meisten Zielgruppen die repräsentativsten Kombinationen. Hören Sie sich an, wie Ihre Produktseite angekündigt wird. Vermittelt der Screenreader alle Informationen, die eine sehende Person erhalten würde? Ergibt der Checkout-Flow Sinn, wenn er linear vorgelesen wird? Und schließlich – und am wertvollsten – testen Sie mit tatsächlichen Nutzerinnen und Nutzern mit Behinderungen. Automatisierte Tools und Entwickler-Tests werden immer Dinge übersehen, auf die reale Nutzer stoßen, weil sie Assistive Technology auf eine bestimmte Weise verwenden.

Für die laufende Compliance sollten Barrierefreiheitsprüfungen in Ihre CI/CD-Pipeline integriert werden, sodass neue Code-Deployments automatisch gescannt werden, bevor sie live gehen. E‑Commerce-Sites ändern sich ständig – neue Aktionen, neue Produktkategorien, neue Checkout-Schritte – und jede Änderung ist eine Gelegenheit, neue Barrieren einzuführen. Barrierefreiheit ist ein Prozess, kein einmaliges Projekt.

Die Frage nach Overlay-Widgets: Was Sie wissen müssen

Wenn Sie sich mit Barrierefreiheitslösungen beschäftigt haben, sind Ihnen mit hoher Wahrscheinlichkeit Overlay-Widgets begegnet – JavaScript-Tools, die versprechen, Ihre Site durch eine Schicht automatischer Korrekturen über Ihrem bestehenden Code konform zu machen. Einige Produkte vermarkten dies als Ein-Zeilen-Lösung. Die Realität ist komplexer, und das Risikoprofil ist erheblich.

Im Jahr 2024 wurden über 1,000 Unternehmen verklagt, obwohl sie Barrierefreiheits-Widgets auf ihren Websites installiert hatten; sie machten mehr als 25% aller ADA-Fälle in diesem Jahr aus. Der Grund ist einfach: Overlays legen eine JavaScript-Schicht über fehlerhaftes HTML, aber Screenreader stoßen auf die zugrunde liegenden Barrieren, bevor die Overlay-Skripte eingreifen können – falls sie überhaupt eingreifen. Overlay-Widgets können zudem eigene Barrierefreiheitsprobleme einführen, darunter Modaldialoge, die den Fokus fangen, und Funktionen, die mit den Einstellungen der eigenen Assistive Technology der Nutzerin oder des Nutzers kollidieren.

Im Januar 2025 verpflichtete die Federal Trade Commission AccessiBe – einen der am aggressivsten vermarkteten Overlay-Anbieter – zur Zahlung von $1 million, um Vorwürfe beizulegen, das Unternehmen habe die Fähigkeit seines Produkts, Websites WCAG-konform zu machen, falsch dargestellt. Kein Gericht hat ein Overlay-Widget als Beleg für ADA-Compliance akzeptiert.

Das bedeutet nicht, dass alle clientseitigen Barrierefreiheits-Tools wertlos sind. Ein gut gebautes Accessibility-SDK – eines, das echte Code-Nachbesserungen ergänzt statt sie zu ersetzen – kann echten Mehrwert bieten: Es kann Nutzerinnen und Nutzern ein Einstellungs-Panel bereitstellen, in dem sie Kontrast, Schriftgröße oder Bewegungseinstellungen anpassen können; eine Barrierefreiheits-Erklärung mit einem klaren Feedback-Kanal bereitstellen; und Nachbesserungen dort sichtbar machen, wo der vollständige Codezugriff begrenzt ist (z. B. bei bestimmten Drittanbieter-Widgets). Der Unterschied ist enorm wichtig: Ein Tool, das Nutzerinnen und Nutzer unterstützt und ordnungsgemäße Nachbesserungen ergänzt, ist kategorisch anders als eines, das behauptet, sie zu ersetzen. Lösungen wie Accsible sind mit dieser Philosophie entwickelt – sie stellen ein SDK bereit, das die User Experience für Besucherinnen und Besucher verbessert, die Anpassungen benötigen, und machen gleichzeitig klar, dass echte Compliance im Code verankert ist.

Ein Barrierefreiheitsprogramm aufbauen, nicht nur Bugs fixen

Der robusteste Weg zu WCAG-Konformität – und derjenige, der am wenigsten wahrscheinlich zu wiederholten Klagen führt – besteht darin, Barrierefreiheit als laufende organisatorische Praxis zu behandeln, nicht als einmaliges technisches Projekt. Nachbesserung ohne Prozessverbesserung ist wie das Ausschöpfen eines leckenden Bootes, ohne das Loch zu flicken.

Beginnen Sie damit, eine Accessibility Statement auf Ihrer Site zu veröffentlichen. Diese Seite sollte den Standard beschreiben, den Sie anstreben (WCAG 2.2 Level AA), die bekannten Einschränkungen Ihrer aktuellen Implementierung, wie Nutzerinnen und Nutzer Barrieren melden können und wie schnell Sie reagieren werden. Das signalisiert guten Willen, gibt Nutzerinnen und Nutzern einen Weg, Hilfe zu suchen, und ist nach EU-Recht ausdrücklich vorgeschrieben. Kombinieren Sie dies mit einem echten Feedback-Mechanismus – einer E‑Mail-Adresse oder einem Formular, das tatsächlich jemanden erreicht, der die Befugnis hat, Dinge zu beheben.

Schulen Sie Ihr gesamtes Team, nicht nur Entwickler. Designerinnen und Designer, die Kontrastverhältnisse und Anforderungen an Fokuszustände verstehen, werden barrierefreie Mockups erstellen. Content-Erstellerinnen und -Ersteller, die wissen, wie man wirksamen Alt-Text schreibt, werden Felder nicht mehr leer lassen. Product Manager, die WCAG verstehen, werden widersprechen, wenn ein vorgeschlagenes Feature keinen Tastaturpfad hat. Über ein Team verteiltes Barrierefreiheitswissen ist weit langlebiger als eine einzelne Accessibility-Spezialistin oder ein einzelner Spezialist, der versucht, am Ende alles abzufangen.

Dokumentieren Sie schließlich Ihre Audit-Ergebnisse, die umgesetzten Korrekturen und die Testergebnisse. Das schafft eine Audit-Trail, der intern – zur Fortschrittsverfolgung – und extern wertvoll ist, als Nachweis ernsthafter Compliance-Bemühungen, falls Sie jemals mit einer Klage konfrontiert werden. Jede vierte Klage im Jahr 2024 betraf Wiederholungstäter, die bereits verklagt worden waren und sich geeinigt hatten, ohne das Problem tatsächlich zu beheben. Ein dokumentiertes, umfassendes Nachbesserungsprogramm ist Ihre beste Verteidigung gegen dieses Ergebnis.

Wesentliche Erkenntnisse

• E‑Commerce ist das Hauptziel von Barrierefreiheitsklagen. Mit einem Anteil von rund 70% an allen ADA-Klagen zur digitalen Barrierefreiheit tragen Online-Shops das höchste Risiko in der digitalen Landschaft. Vergleiche liegen routinemäßig bei $25,000–$75,000 plus Nachbesserungskosten, und ein früherer Vergleich schützt Sie nicht vor weiteren Klagen, wenn die Barrieren bestehen bleiben.
• Zielen Sie auf WCAG 2.2 Level AA – damit decken Sie 2.1 und 2.0 automatisch ab. WCAG 2.2 ist abwärtskompatibel, sodass das Anstreben des neuesten Standards Ihnen die breiteste rechtliche Abdeckung über US-Gerichte, den European Accessibility Act der EU und die meisten anderen Rechtsordnungen weltweit bietet.
• Beheben Sie zuerst den Kauftrichter. Der Checkout-Flow – vom Warenkorb bis zur Bestellbestätigung – ist der Bereich mit den risikoreichsten Barrieren und der Stelle, an der Nutzerinnen und Nutzer mit Behinderungen am ehesten abbrechen. Priorisieren Sie Tastaturzugänglichkeit, Formularlabels, Fehlerbehandlung und Ankündigungen dynamischer Inhalte über alle Checkout-Schritte hinweg.
• Automatisierte Tools erfassen nur 30–40% der WCAG-Probleme. Ergänzen Sie automatisiertes Scannen durch Tests nur mit der Tastatur, Screenreader-Tests und Sessions mit echten Nutzerinnen und Nutzern. Integrieren Sie Barrierefreiheitsprüfungen in Ihre CI/CD-Pipeline, damit neuer Code keine Regressionen einführt.
• Barrierefreiheit ist ein Programm, kein Patch. Schulen Sie Ihre Designer, Entwickler und Content-Teams. Veröffentlichen Sie eine Accessibility Statement mit einem echten Feedback-Kanal. Dokumentieren Sie Ihre Nachbesserungsarbeit. Verankern Sie Barrierefreiheit in Ihrem Entwicklungsprozess, damit sie erhalten bleibt, während sich Ihr Shop weiterentwickelt.