Accessibility testing for your customers' path to checkout
By keyboard, in your pipeline: Playwright tests walk product → cart → checkout, or a booking, step by step on every pull request. For web agencies and for the people who run online shops and booking sites.
What's at stake for your shop
Accessibility is not a badge. It decides whether part of your customers can buy, and how authorities and the public see you.
One in four adults
About 90 million people in the EU, one in four adults, have a disability (Eurostat, 2024). Many shop with a keyboard, a screen reader or zoom. If checkout fails for them, they cannot buy from you.
Source: Council of the EU: Disability in the EU, facts and figures (Eurostat 2024)
Authorities can order fixes and public notice
In Austria, consumers, the VKI and the Behindertenrat can report a shop to the Sozialministeriumservice. It first asks for a fix, then can order the shop to inform the public or stop the service. Fines go up to €80,000 (€50,000 for SMEs). In Slovakia the SOI follows up complaints from anyone; fines go up to €6,000 for missing accessibility requirements or information, and up to €20,000 or €30,000 for other breaches, such as not taking corrective measures or not cooperating with the authority.
Source: Barrierefreiheitsgesetz (BaFG), Austria (RIS); Act No. 351/2022 Coll., Slovakia (Slov-Lex)
Germany, Czechia and Austria add their own rules
In Germany the Barrierefreiheitsstärkungsgesetz (BFSG) has applied since 28 June 2025; offering an inaccessible service can be fined up to €100,000 (§ 37 BFSG). In Czechia, Act No. 424/2023 Coll. has applied since the same day; the Czech Trade Inspection Authority (ČOI) supervises e-shops, with fines up to CZK 10,000,000. In Austria, a customer who is discriminated against can claim damages under the BGStG, after a conciliation procedure at the Sozialministeriumservice.
Source: Barrierefreiheitsstärkungsgesetz (BFSG), § 37, Germany (gesetze-im-internet.de); Act No. 424/2023 Coll., Czechia (e-Sbírka); Bundes-Behindertengleichstellungsgesetz (BGStG), Austria (RIS)
Late fixes cost more
A public notice of non-compliance is hard to undo, and a fix after a complaint means a deadline and a rushed release. A failing test in the pull request shows the bug before the release.
Why a scanner on its own is not enough
Scanners check pages, not journeys
A scanner loads single pages. It does not use the keyboard to go from product to cart to checkout, or through a booking. That is where customers without a mouse get stuck and can't buy. And scanners only find part of the issues.
Findings sit in a PDF, not in the pull request
An audit report gets read and filed. Developers don't see it while they work. With the next release the same bugs come back, often unnoticed.
Your accessibility information goes stale
Since 28 June 2025 the European Accessibility Act, through the BaFG (AT) and Act 351/2022 (SK), requires online shops to publish accessibility information (in AT per Anlage 3). Every release can make it untrue unless the journeys are tested again.
What the tests check
Each test follows a real path through your site and presses Tab, Enter and Esc like a person without a mouse. Every finding names its WCAG criterion.
Keyboard reachability
Every control in the journey must be reachable with Tab. If a target never gets focus, the test fails.
- Buttons, links and form fields
- Cookie banner closed by keyboard
- A set limit of Tab presses per target
Focus order (WCAG 2.4.3)
After each Tab the test records where focus is and compares it with the expected order.
- Expected order for each form
- Differences shown as a diff in the report
- For example email, name, address, country
Visible focus (WCAG 2.4.7)
Keyboard users need to see where they are. The test compares each element with and without focus.
- Outline, shadow and border
- Screenshot comparison as a fallback
- On desktop and mobile
No keyboard traps (WCAG 2.1.2)
You can leave every widget with Tab or Esc. Dialogs take focus when they open and give it back when they close.
- Tab leaves every widget
- Esc closes dialogs
- Focus returns to the trigger
Form errors (WCAG 3.3.1, 3.3.3)
Error messages must be announced and linked to their field. We check this on staging only, with test data.
- aria-invalid and aria-describedby
- Focus moves to the first error
- Staging only, synthetic data only
axe scan and ARIA snapshots
axe-core scans your key URLs. ARIA snapshots of checkout, cart and navigation show when labels go missing between releases.
- axe rules for WCAG 2.0 to 2.2, A and AA
- New serious findings fail the build
- Known issues with an owner and an end date
How it works
Pick the journeys together
We agree with you which paths matter: for example product → cart → checkout up to the payment choice, a booking or the contact form.
Tests in your repository
The tests, built with Playwright and axe-core, are committed to your repo as code. Your team can read, change and extend them.
On every pull request in CI
GitHub Actions, GitLab CI or Jenkins runs the tests on every pull request against the preview URL. Each night a read-only run checks production.
Report and statement
You get a white-label report. We update the draft of your accessibility statement with the new results.
What a finding looks like
An invented example for illustration only. It does not come from a real client or a real website. This is how a failed test appears in the report.
Illustrative example
- Journey step
- Product page → “Add to cart” (on staging) → mini-cart → “Go to checkout”
- Expected
- Focus moves into the mini-cart. “Go to checkout” can be reached with Tab, and Esc closes the dialog (WCAG 2.4.3, 2.1.2).
- What happened
- The dialog opens, but keyboard focus never enters it. “Go to checkout” cannot be reached by keyboard.
- Why it matters
- People who shop by keyboard never reach checkout. These customers can't buy. The test fails in the pull request, before the bug goes live.
Where to start
Start with a free check of one journey. The ongoing packages begin with two journeys and grow with your shop.
Free journey check
Free
One public journey, read-only and only with your permission. We submit no forms, add nothing to the cart and buy nothing.
- Report typically within 3 working days
- One public journey, by keyboard
- Short report with WCAG criteria
- 15-minute walkthrough of the results
Basis
from €900 setup + €150/month
Two journeys in your CI, with monthly upkeep after changes to the interface.
- Set up typically within 5 working days
- 2 journeys, axe scan of up to 10 key URLs
- CI config for one pipeline
- First report and an accessibility statement draft
- Monthly: keep tests green after UI changes (up to 1 h)
- Monthly: production run, report and statement update
Shop, Shop Plus and agency
On request
For larger shops, booking sites and agencies with several client sites.
- Set up typically in 2–4 weeks
- More journeys: checkout, login, booking widgets
- Quarterly manual screen-reader check (Shop Plus)
- White-label for several sites (agency package)
All prices exclude VAT. Larger scopes are quoted after a short call.
For web agencies
Looking after several shops? Reports appear under your agency's name. All client sites share one template repository. Your developers see failing tests on their own pull requests, not weeks later in a PDF.
- White-label reports with your logo and colors
- One shared template repo for all client sites
- Failures shown on the developer's own pull request
Access and data
- Read-only on production: navigating, pressing Tab, opening and closing dialogs. Nothing is submitted or bought.
- We test forms on staging only, with synthetic test data.
- Staging and test-account credentials stay in your CI secret store, never in the repository.
- We only work with written authorization: scope, environments and time windows.
- Third-party payment and booking widgets are tested up to the hand-off to the provider.
What this is not
- Automated and scripted checks cover only part of WCAG 2.2 / EN 301 549 V3.2.1 (which references WCAG 2.1). A manual screen-reader check is included in Shop Plus only.
- Not a certificate of accessibility and not legal advice. The tests and reports help you prepare.
- The shop operator publishes the accessibility statement and is responsible for it. We draft it and keep it up to date.
- Results are a snapshot of the version tested.
Automated and scripted checks cover only part of the requirements of WCAG 2.2 / EN 301 549 V3.2.1 (which references WCAG 2.1). Not a certificate of conformity, not legal advice.
Legal sources (checked on October 19, 2026)
- Council of the EU: Disability in the EU, facts and figures (Eurostat 2024)
- Barrierefreiheitsgesetz (BaFG), Austria (RIS)
- WKO: Barrierefreiheitsgesetz and e-commerce
- Act No. 351/2022 Coll., Slovakia (Slov-Lex)
- Bundes-Behindertengleichstellungsgesetz (BGStG), Austria (RIS)
- Barrierefreiheitsstärkungsgesetz (BFSG), § 37, Germany (gesetze-im-internet.de)
- Act No. 424/2023 Coll., Czechia (e-Sbírka)
Questions
Does the law apply to us at all?
For consumer online shops and booking services, yes. Micro-enterprises that provide services are exempt: fewer than 10 staff and no more than €2 million in annual turnover or balance sheet total. Accessibility is still good practice, because those customers want to buy too.
Does this replace a manual audit?
No. An audit also covers what cannot be automated. Our tests keep the journeys you care about from breaking again between two audits.
Which CI systems do you support?
GitHub Actions, GitLab CI and Jenkins. The tests run in the official Playwright container. Results come as JUnit XML for your CI and as an HTML report for your team.
What about third-party payment or booking widgets?
We test up to the hand-off to the provider. What happens after that we can neither test nor change. We list those parts in the report and in the statement as third-party content.
Who publishes the accessibility statement?
You, as the shop operator, and you are responsible for its content. We draft it from the test results and your answers (in Austria per Anlage 3 BaFG) and keep it up to date.
Do you need access to production?
No. On production the tests are read-only, with no orders and no forms. We test forms on staging with test data. Credentials stay in your CI secret store.
Let us test one of your journeys
Name one public journey. With your permission we test it read-only and walk you through the results in 15 minutes.