Example scenario: how an online shop implements accessibility
This article shows how an online shop can move from identifying accessibility problems to remediation, automated checks and manual verification.
Starting point
Imagine a medium-sized online shop that sells to customers in the EU. Its development team has several members and deploys changes regularly. Management is aware of the European Accessibility Act (EAA), but accessibility has not yet been addressed systematically—only issues that someone specifically complained about have been fixed.
What usually happens
The subject is raised by an external prompt: an article, a question from a lawyer or a customer complaint that may be followed by an inspection. The company commissions a one-off audit and receives a PDF with 180 findings. And that is where it ends.
The report was written for an auditor, not a developer. Half the findings are the same defect repeated across twenty pages. No one knows where to begin or which issues are truly critical. Even if some findings are resolved, a redesign six months later brings the problems back.
That is the heart of the issue: accessibility is not a one-off fix and can deteriorate as changes are made. The machine-testable portion can be monitored with automated checks following agreed changes, while the rest requires regular manual verification.
How to move from findings to continuous checks
We begin with a free initial scan of key pages. This is not an audit, but an initial estimate of machine-detectable issues within the agreed scope.
We then select axe-core, IBM Equal Access or a suitable combination based on the scope, and integrate the checks into your CI/CD—for example, GitHub Actions or GitLab CI. More tools are not automatically better: their rules can overlap, so we consolidate the results and remove duplicates. During agreed runs, the checks can flag newly introduced machine-detectable issues shortly after a change.
We do not run checks only on static pages. With Playwright, we can prepare states that appear only after an interaction: after sign-in, after a modal window opens and at the individual stages of the checkout and forms. A static scan alone cannot reach these states without a prepared scenario; even after they are opened, however, automation covers only the machine-detectable portion.
We structure the report by severity and map findings to the relevant WCAG and EN 301 549 criteria. Each finding includes a recommended fix, and duplicates are consolidated. Developers receive a list of specific tasks, while management gets an overview of the current state.
We use WCAG 2.2 as the more current professional target. For a mandatory assessment, we also verify which version of the standard is required by the applicable legal or contractual framework. An automated report is not, by itself, legal confirmation of compliance.
What this approach gives you
- Instead of relying on impressions, you know where you stand and have evidence to support it.
- You reduce the risk that a previously fixed, machine-detectable issue will return unnoticed.
- You have technical evidence of the assessed state in case of an inspection, although this is not automatic proof of legal compliance.
- Developers receive findings while the code is still fresh in their minds, not six months later.
First step
A free initial scan provides an initial estimate of machine-detectable issues within the agreed scope, for example on selected pages in the purchase journey and forms. We will agree its scope during a no-obligation consultation.