A one-off audit was not enough
The project began while the client was preparing for the European Accessibility Act. Directive (EU) 2019/882, known as the European Accessibility Act (EAA), has applied since 28 June 2025 to selected products and services provided to consumers. E-commerce services are among those covered. In Slovakia, this area is regulated by Act No. 351/2022 Coll. on the accessibility of products and services for persons with disabilities.
The scope of the obligations depends on the product or service, the position of the business and any applicable exemptions. This project did not provide a legal assessment of the client. Its purpose was to establish recurring technical checks and continuously detect issues that automated tools can identify reliably.
The client needed more than an audit result that reflected a single day. It needed a repeatable process that would check every URL in the sitemap each day, follow selected critical customer journeys and send the results to the people responsible for fixes.
We paired the sitemap with real customer journeys
We built the solution with Selenium and axe-core. Selenium controlled the browser and moved through pages and defined user steps. Axe-core ran automatically verifiable accessibility checks related to WCAG in each state of the interface.
WCAG 2.2 is the current W3C Recommendation for web content accessibility. It extends WCAG 2.1 with additional criteria, and W3C advises using the latest version when creating or updating accessibility policies. The version required for a legal or contractual assessment must still be confirmed against the relevant framework. Our comparison of WCAG 2.1 and WCAG 2.2 explains the differences.
A sitemap covers page addresses, not everything that appears while someone uses the website. Some parts of an interface become available only after an interaction. Following the customer journeys extended the checks beyond individual URLs to states reached during an actual process.
On each scheduled run, the framework:
- loaded every URL from the sitemap
- visited each page
- ran an automated accessibility check on every page
- followed the defined critical customer journeys
- repeated the checks in application states available only after specific user actions
The report showed the finding and where to fix it
Each run produced a combined report in HTML and JSON. The HTML version let the team browse findings and open their details. JSON contained the same results in a structured format.
The team did not have to search for the issue again after receiving the report. It showed the page, affected element, severity and information needed for a fix. The screenshot and selector helped distinguish similar elements and locate the right place in the application or code more quickly.
Where available, each finding included:
- the URL or location
- the type of accessibility issue
- a description of the finding
- its severity
- a recommended fix
- the selector of the affected element
- a screenshot of that element
- additional technical details
Results reached the team every day
The sitemap and customer journey checks ran automatically once a day. When a run finished, the HTML and JSON results were emailed to the people responsible for resolving accessibility issues.
The path from finding to fix followed the same steps each time. The check identified the issue, the report recorded its location and severity, and the supporting technical information reached the responsible team. Nobody had to run the same scan manually or prepare the output each day.
Automated checks cannot verify everything
The automated checks did not replace full manual accessibility testing. W3C notes that evaluation tools cannot check every aspect of accessibility automatically and that some assessments require human judgement. Automation can find machine-detectable issues regularly and consistently. It cannot confirm on its own that the entire website is accessible or that the service meets every legal requirement. Our article on what an automated accessibility scanner can and cannot detect explains this distinction in more detail.
Broader professional assessments also use the European standard EN 301 549. Its 2021 version is harmonised for the directive on the accessibility of public-sector websites and mobile applications. AccessibleEU states that the standard is being updated to support the EAA as well. A legal assessment must therefore use the relevant legislation and current standards, not only the result from axe-core.
What changed for the client
- The client gained an automated framework supporting ongoing WCAG checks and EAA compliance activities.
- Every URL in the sitemap was checked each day.
- The checks also covered critical customer journeys.
- Findings were tied to specific pages and elements.
- The report included the severity, issue details and a recommended fix.
- Each finding included the selector and a screenshot of the affected element when available.
- Results were generated in HTML and JSON and sent automatically to the responsible people.
- Accessibility checks became a recurring part of website quality control instead of a one-off activity.
- The result did not provide automatic confirmation of compliance. It gave the team a repeatable way to detect machine-verifiable issues, locate them in the interface and start resolving them.