Barrierefreiheit testen – auf dem Weg Ihrer Kunden zur Kasse
Per Tastatur und in Ihrer Pipeline: Playwright-Tests gehen Produkt → Warenkorb → Kasse oder eine Buchung Schritt für Schritt durch, bei jedem Pull Request. Für Web-Agenturen und Betreiber von Online-Shops und Buchungsseiten.
Was für Ihren Shop auf dem Spiel steht
Barrierefreiheit ist kein Gütesiegel. Sie entscheidet, ob ein Teil Ihrer Kunden kaufen kann und wie Behörden und Öffentlichkeit Sie sehen.
Jeder vierte Erwachsene
Rund 90 Millionen Menschen in der EU, jeder vierte Erwachsene, leben mit einer Behinderung (Eurostat, 2024). Viele kaufen per Tastatur, Screenreader oder Zoom ein. Scheitert der Checkout für sie, können sie bei Ihnen nicht kaufen.
Quelle: Rat der EU: Behinderung in der EU, Fakten und Zahlen (Eurostat 2024)
Behörden können Korrektur und öffentliche Information anordnen
In Österreich können Verbraucher, der VKI und der Behindertenrat einen Shop beim Sozialministeriumservice melden. Es fordert zuerst eine Korrektur und kann dann die Information der Öffentlichkeit oder die Einstellung des Angebots anordnen. Strafen gehen bis 80.000 € (50.000 € für KMU). In der Slowakei geht die SOI Beschwerden von allen nach; Strafen bis 6.000 € bei fehlender Barrierefreiheit oder fehlenden Informationen, bis 20.000 € oder 30.000 € bei anderen Verstößen, etwa fehlenden Korrekturmaßnahmen oder fehlender Mitwirkung gegenüber der Behörde.
Quelle: Barrierefreiheitsgesetz (BaFG), Österreich (RIS); Gesetz Nr. 351/2022 Slg., Slowakei (Slov-Lex)
Deutschland: Bußgeld nach BFSG, Österreich: Schadenersatz
In Deutschland gilt seit 28. Juni 2025 das Barrierefreiheitsstärkungsgesetz (BFSG) auch für Online-Shops und Buchungsangebote für Verbraucher; zuständig ist die Marktüberwachungsstelle der Länder (MLBF) mit Sitz in Sachsen-Anhalt, und wer eine nicht barrierefreie Dienstleistung anbietet, riskiert ein Bußgeld bis 100.000 € (§ 37 BFSG). In Österreich gilt das Bundes-Behindertengleichstellungsgesetz (BGStG) im Bereich der Bundeskompetenz für Waren und Dienstleistungen, die der Öffentlichkeit angeboten werden; wer diskriminiert wird, kann nach einem Schlichtungsverfahren beim Sozialministeriumservice Schadenersatz verlangen.
Quelle: Barrierefreiheitsstärkungsgesetz (BFSG), § 37, Deutschland (gesetze-im-internet.de); Gesetz Nr. 424/2023 Slg., Tschechien (e-Sbírka); Bundes-Behindertengleichstellungsgesetz (BGStG), Österreich (RIS)
Späte Korrekturen kosten mehr
Eine öffentliche Information über Mängel lässt sich schwer zurücknehmen, und eine Korrektur nach einer Beschwerde heißt Frist und hektisches Release. Ein roter Test im Pull Request zeigt den Fehler vor dem Release.
Warum ein Scanner allein nicht reicht
Scanner prüfen Seiten, keine Wege
Ein Scanner lädt einzelne Seiten. Er geht nicht per Tastatur von Produkt zu Warenkorb und Kasse oder durch eine Buchung. Genau dort scheitern Kunden ohne Maus und kaufen nicht. Zudem finden Scanner nur einen Teil der Probleme.
Befunde landen im PDF, nicht im Pull Request
Ein Audit-Bericht wird gelesen und abgelegt. Die Entwickler sehen ihn bei der Arbeit nicht. Mit dem nächsten Release kommen dieselben Fehler zurück, oft unbemerkt.
Ihre Barrierefreiheits-Infos veralten
Seit 28. Juni 2025 müssen Online-Shops nach dem European Accessibility Act, umgesetzt im BFSG (DE), BaFG (AT) und Gesetz 351/2022 (SK), Infos zur Barrierefreiheit veröffentlichen (DE und AT: jeweils Anlage 3). Jedes Release kann sie unwahr machen, wenn die Journeys nicht erneut getestet werden.
Was die Tests prüfen
Jeder Test folgt einem echten Weg durch Ihre Website und drückt Tab, Enter und Esc wie ein Mensch ohne Maus. Bei jedem Befund steht das WCAG-Kriterium.
Erreichbarkeit per Tastatur
Jedes Bedienelement im Weg muss per Tab erreichbar sein. Wird ein Ziel nie fokussiert, schlägt der Test fehl.
- Buttons, Links und Formularfelder
- Cookie-Banner per Tastatur schließen
- Feste Obergrenze an Tab-Schritten je Ziel
Fokus-Reihenfolge (WCAG 2.4.3)
Der Test hält nach jedem Tab fest, wo der Fokus steht, und vergleicht das mit der erwarteten Reihenfolge.
- Erwartete Reihenfolge je Formular
- Abweichungen als Diff im Bericht
- Etwa E-Mail, Name, Adresse, Land
Sichtbarer Fokus (WCAG 2.4.7)
Wer per Tastatur navigiert, muss sehen, wo er gerade ist. Der Test vergleicht jedes Element mit und ohne Fokus.
- Outline, Schatten und Rahmen
- Screenshot-Vergleich als Rückfallebene
- Auf Desktop und Mobil
Keine Tastaturfallen (WCAG 2.1.2)
Aus jedem Widget kommt man per Tab oder Esc wieder heraus. Dialoge übernehmen den Fokus und geben ihn danach zurück.
- Tab verlässt jedes Widget
- Esc schließt Dialoge
- Fokus kehrt zum Auslöser zurück
Formularfehler (WCAG 3.3.1, 3.3.3)
Fehlermeldungen müssen angesagt werden und mit dem Feld verknüpft sein. Das prüfen wir nur auf Staging, mit Testdaten.
- aria-invalid und aria-describedby
- Fokus springt zum ersten Fehler
- Nur Staging, nur synthetische Daten
axe-Scan und ARIA-Snapshots
axe-core prüft zentrale URLs Ihrer Website. ARIA-Snapshots von Kasse, Warenkorb und Navigation zeigen, wenn Beschriftungen zwischen Releases verloren gehen.
- axe-Regeln für WCAG 2.0 bis 2.2, A und AA
- Neue schwere Befunde stoppen den Build
- Bekannte Fälle mit Zuständigkeit und Frist
So läuft es ab
Journeys gemeinsam auswählen
Wir legen mit Ihnen fest, welche Wege zählen: etwa Produkt → Warenkorb → Kasse bis zur Wahl der Zahlungsart, eine Buchung oder das Kontaktformular.
Tests in Ihrem Repository
Die Tests mit Playwright und axe-core kommen als Code in Ihr Repo. Ihr Team kann sie lesen, ändern und erweitern.
Bei jedem Pull Request in der CI
GitHub Actions, GitLab CI oder Jenkins führt die Tests bei jedem Pull Request gegen die Preview-URL aus. Jede Nacht läuft ein Durchgang nur lesend auf der Produktion.
Bericht und Erklärung
Sie erhalten einen White-Label-Bericht. Den Entwurf Ihrer Barrierefreiheitserklärung bringen wir mit den neuen Ergebnissen auf den aktuellen Stand.
So sieht ein Befund aus
Ein erfundenes Beispiel zur Veranschaulichung. Es stammt von keinem echten Kunden und keiner echten Website. So erscheint ein fehlgeschlagener Test im Bericht.
Beispiel zur Veranschaulichung
- Schritt in der Journey
- Produktseite → „In den Warenkorb“ (auf Staging) → Mini-Warenkorb → „Zur Kasse“
- Erwartet
- Der Fokus wechselt in den Mini-Warenkorb. „Zur Kasse“ ist per Tab erreichbar, Esc schließt den Dialog (WCAG 2.4.3, 2.1.2).
- Was passiert ist
- Der Dialog öffnet sich, aber der Fokus kommt nie hinein. „Zur Kasse“ ist per Tastatur nicht erreichbar.
- Warum es zählt
- Wer per Tastatur einkauft, kommt nicht zur Kasse. Diese Kunden können nicht kaufen. Der Test schlägt im Pull Request fehl, bevor der Fehler live geht.
Womit Sie starten
Beginnen Sie mit einem kostenlosen Check einer Journey. Die laufenden Pakete starten mit zwei Journeys und wachsen mit Ihrem Shop.
Kostenloser Journey-Check
Kostenlos
Eine öffentliche Journey, nur lesend und nur mit Ihrer Erlaubnis. Wir senden keine Formulare ab, legen nichts in den Warenkorb und kaufen nichts.
- Bericht in der Regel innerhalb von 3 Arbeitstagen
- Eine öffentliche Journey per Tastatur
- Kurzer Bericht mit WCAG-Kriterien
- 15 Minuten Durchsprache der Ergebnisse
Basis
ab 900 € Einrichtung + 150 €/Monat
Zwei Journeys in Ihrer CI, mit monatlicher Pflege nach Änderungen an der Oberfläche.
- Einrichtung in der Regel innerhalb von 5 Arbeitstagen
- 2 Journeys, axe-Scan von bis zu 10 zentralen URLs
- CI-Konfiguration für eine Pipeline
- Erster Bericht und Entwurf der Barrierefreiheitserklärung
- Monatlich: Tests nach UI-Änderungen grün halten (bis 1 h)
- Monatlich: Lauf auf Produktion, Bericht, Update der Erklärung
Shop, Shop Plus und Agentur
Auf Anfrage
Für größere Shops, Buchungsseiten und Agenturen mit mehreren Kundenseiten.
- Einrichtung in der Regel in 2–4 Wochen
- Mehr Journeys: Kasse, Login, Buchungs-Widgets
- Vierteljährlicher manueller Screenreader-Check (Shop Plus)
- White-Label für mehrere Websites (Agentur-Paket)
Alle Preise zzgl. USt. Größere Umfänge bieten wir nach einem kurzen Gespräch an.
Für Web-Agenturen
Sie betreuen mehrere Shops? Die Berichte erscheinen unter Ihrem Namen. Alle Kundenseiten nutzen ein gemeinsames Template-Repository. Ihre Entwickler sehen fehlgeschlagene Tests in ihren eigenen Pull Requests, nicht Wochen später in einem PDF.
- White-Label-Berichte mit Ihrem Logo und Ihren Farben
- Ein gemeinsames Template-Repo für alle Kundenseiten
- Fehler direkt im eigenen Pull Request
Zugänge und Daten
- Auf der Produktion nur lesend: navigieren, Tab drücken, Dialoge öffnen und schließen. Nichts wird abgesendet oder gekauft.
- Formulare testen wir nur auf Staging, mit synthetischen Testdaten.
- Zugangsdaten für Staging und Testkonten liegen im Secret Store Ihrer CI, nie im Repository.
- Wir arbeiten nur mit schriftlicher Freigabe: Umfang, Umgebungen und Zeitfenster.
- Zahlungs- und Buchungs-Widgets von Drittanbietern testen wir bis zur Übergabe an den Anbieter.
Was dieser Service nicht ist
- Automatisierte und skriptbasierte Prüfungen decken nur einen Teil von WCAG 2.2 / EN 301 549 V3.2.1 (die auf WCAG 2.1 verweist) ab. Einen manuellen Screenreader-Check gibt es nur in Shop Plus.
- Keine Bescheinigung der Barrierefreiheit und keine Rechtsberatung. Tests und Berichte helfen Ihnen bei der Vorbereitung.
- Die Barrierefreiheitserklärung veröffentlicht und verantwortet der Shop-Betreiber. Wir entwerfen sie und halten sie aktuell.
- Die Ergebnisse sind eine Momentaufnahme des getesteten Stands.
Automatisierte und skriptbasierte Prüfungen decken nur einen Teil der Anforderungen nach WCAG 2.2 / EN 301 549 V3.2.1 (die auf WCAG 2.1 verweist) ab. Kein Konformitätszertifikat, keine Rechtsberatung.
Rechtsquellen (geprüft am 19. Oktober 2026)
- Rat der EU: Behinderung in der EU, Fakten und Zahlen (Eurostat 2024)
- Barrierefreiheitsgesetz (BaFG), Österreich (RIS)
- WKO: Barrierefreiheitsgesetz im E-Commerce
- Gesetz Nr. 351/2022 Slg., Slowakei (Slov-Lex)
- Bundes-Behindertengleichstellungsgesetz (BGStG), Österreich (RIS)
- Barrierefreiheitsstärkungsgesetz (BFSG), § 37, Deutschland (gesetze-im-internet.de)
- Gesetz Nr. 424/2023 Slg., Tschechien (e-Sbírka)
Häufige Fragen
Betrifft uns das Gesetz überhaupt?
Online-Shops und Buchungsangebote für Verbraucher: ja. Ausgenommen sind Kleinstunternehmen, die Dienstleistungen erbringen, also mit weniger als 10 Beschäftigten und höchstens 2 Mio. € Jahresumsatz oder Bilanzsumme. Gute Praxis bleibt Barrierefreiheit trotzdem, denn auch diese Kunden wollen kaufen.
Ersetzt das ein manuelles Audit?
Nein. Ein Audit prüft auch, was sich nicht automatisieren lässt. Unsere Tests sorgen dafür, dass die geprüften Wege zwischen zwei Audits nicht wieder kaputtgehen.
Welche CI-Systeme unterstützen Sie?
GitHub Actions, GitLab CI und Jenkins. Die Tests laufen im offiziellen Playwright-Container. Ergebnisse gibt es als JUnit-XML für Ihre CI und als HTML-Bericht für Ihr Team.
Was ist mit Zahlungs- oder Buchungs-Widgets von Drittanbietern?
Wir testen bis zur Übergabe an den Anbieter. Was danach kommt, können wir weder testen noch ändern. Diese Teile führen wir im Bericht und in der Erklärung als Inhalte Dritter auf.
Wer veröffentlicht die Barrierefreiheitserklärung?
Sie als Shop-Betreiber, und Sie verantworten den Inhalt. Wir erstellen den Entwurf nach Anlage 3 BFSG (Deutschland) oder Anlage 3 BaFG (Österreich) aus den Testergebnissen und Ihren Angaben und halten ihn aktuell.
Brauchen Sie Zugang zur Produktion?
Nein. Auf der Produktion laufen die Tests nur lesend, ohne Bestellung und ohne Formulare. Formulare testen wir auf Staging mit Testdaten. Zugangsdaten bleiben im Secret Store Ihrer CI.
Verwandte Projekte
Testautomatisierung in der Praxis
Testen wir eine Ihrer Journeys
Nennen Sie uns eine öffentliche Journey. Mit Ihrer Erlaubnis testen wir sie nur lesend und gehen das Ergebnis in 15 Minuten mit Ihnen durch.