Seite 9 - Barrierefreiheit

Sobald ein Shopbetreiber oder eine Agentur an einer öffentlichen Ausschreibung teilnimmt oder einen größeren B2B-Kunden gewinnen will, taucht früher oder später die Frage nach einem VPAT auf. Wer dieses Dokument nicht liefern kann, verliert oft schon vor der eigentlichen technischen Prüfung.

Jedes Mal, wenn eine Farbe, ein Abstand oder eine Schriftgröße frei und ad hoc gewählt wird, entsteht ein neues Risiko für eine Kontrast-, Touch-Target- oder Skalierbarkeits-Barriere, die anschließend einzeln wieder gefunden und behoben werden muss. Design-Tokens verschieben diese Entscheidung von der einzelnen Komponente auf die Ebene des gesamten Design-Systems: Wird ein Farb-Token einmal korrekt gegen Kontrastanforderungen geprüft, profitiert jede Komponente, die dieses Token verwendet, automatisch davon. Dieser Artikel zeigt, wie Farb-, Spacing- und Typography-Tokens Barrierefreiheit strukturell statt punktuell im gesamten Team verankern.

WCAG 2.2 wurde im Oktober 2023 vom W3C als Empfehlung verabschiedet und bringt neun neue Erfolgskriterien mit, die WCAG 2.1 gezielt ergänzen. Für Shops, die bereits auf 2.1 AA geprüft sind, bedeutet das keinen Neustart, aber eine konkrete Liste an zusätzlichen Prüfpunkten, die vor allem im Checkout spürbar werden.

Wer barrierefreie Interfaces bauen will, braucht keine teure Zusatzsoftware. Chrome und Firefox liefern mit dem Accessibility-Panel, der Computed-Name-Anzeige und der Simulation von Farbfehlsichtigkeiten bereits alle Werkzeuge, um Rollen, Namen und Kontraste direkt im Browser zu prüfen. Dieser Artikel zeigt, wie diese Bordmittel gezielt eingesetzt werden und wo der Lighthouse Accessibility Audit an seine Grenzen stößt.

Die klassischen Pseudo-Klassen :valid und :invalid feuern, sobald ein Formularfeld existiert, oft schon vor dem ersten Tastendruck. Das führt zu roten Rahmen um leere Pflichtfelder direkt beim Laden der Seite. Die neueren Pseudo-Klassen :user-valid und :user-invalid warten dagegen auf echte Nutzerinteraktion und lösen dieses Problem vollständig ohne JavaScript.

Ein Accessibility Statement ist seit dem BFSG keine Kür mehr, sondern eine rechtliche Pflicht mit klar definierten Inhalten. Wer bekannte Einschränkungen ehrlich dokumentiert, einen funktionierenden Feedback-Mechanismus bereitstellt und die Erklärung regelmäßig aktualisiert, erfüllt die Anforderungen von BFSG und EAA und schützt sein Unternehmen vor Abmahnungen.

Ein rot umrandetes Eingabefeld nützt Screenreader-Nutzern nichts, wenn der Fehler nicht programmatisch mit dem Feld verknüpft ist. Dieser Artikel zeigt, wie aria-invalid, aria-describedby und Live-Regionen Validierungsfehler zuverlässig ankündigen, inklusive eines vollständigen, barrierefreien Checkout-Beispiels für Magento und Hyvä.

Automatisierte Accessibility-Tests mit axe-core decken rund ein Drittel aller WCAG-Verstöße zuverlässig auf und lassen sich direkt in eine bestehende Playwright- oder Cypress-Suite integrieren. Mit einer Baseline-Strategie schlägt der Build nur bei neuen Verstößen fehl, während bekannte Altlasten sichtbar bleiben, statt die Pipeline dauerhaft zu blockieren. Manuelle Prüfung bleibt für Tastaturbedienung und Screenreader unverzichtbar.

Barrierefreiheit gilt oft als Nischenthema für eine kleine Gruppe von Screenreader-Nutzern, dabei betrifft sie fast jeden: ein gebrochenes Handgelenk, grelles Sonnenlicht auf dem Display, Einhand-Bedienung im Bus oder nachlassende Sehkraft im Alter. Wer barrierefrei entwickelt, baut gleichzeitig robustere und schnellere Interfaces für alle Nutzer eines Magento-Shops, nicht nur für eine Minderheit.

Chat-Buttons, die per Tastatur nicht erreichbar sind, Fokus-Fallen beim Öffnen des Chat-Fensters und Nachrichten, die Screenreadern verborgen bleiben: Live-Chat-Widgets gehören zu den am häufigsten übersehenen Barrieren im E-Commerce-Frontend.