The European Accessibility Act is not a general badge for every website. It sets requirements for defined products and consumer services, including e-commerce.
The 2026 WebAIM Million automated scan found detectable WCAG failures on 95.9 percent of one million home pages, averaging 56.1 errors each. The test covers roughly 50 automated rules and cannot establish full conformance or legal non-compliance, but it shows how common basic barriers remain after the Act’s main application date. The figure has moved the wrong way: the 2025 scan found 94.8 percent and 51 errors.
Directive (EU) 2019/882 applies to specified products placed on the market after 28 June 2025 and specified consumer services provided after that date. E-commerce services are expressly listed.
The deadline has passed. The first job is still scope, not panic.
Start with the service, not the domain
The directive defines an e-commerce service as a service provided at a distance, through websites and mobile services, electronically and at the individual request of a consumer, with a view to concluding a consumer contract.
A corporate information site is not automatically in scope merely because it has pages. A store, booking service or consumer purchase flow may be. Other listed services include consumer banking, e-books, electronic communications and parts of passenger transport.
Map what the organisation provides, whether the recipient is a consumer, whether the site enables a consumer contract, which countries receive the service, which legal entity provides it, and whether another listed product or service applies.
Do not stop at the homepage. Product search, authentication, checkout, payment, confirmation and support may form one service.
The directive also contains exclusions. Website content exclusions include certain pre-recorded time-based media and office files published before 28 June 2025, third-party content outside the operator’s funding, development or control, and qualifying archives not updated after that date. Microenterprises providing services are excluded at EU-directive level, while national implementation and other laws still need review.
Obligations can also be subject to fundamental-alteration and disproportionate-burden provisions. Those are documented assessments, not a button labelled “too expensive.”
The requirement reaches the transaction
For e-commerce, Annex I requires information about the accessibility of products and services being sold when that information is provided by the responsible economic operator. It also requires identification, security and payment functions to be accessible when delivered as part of the service.
The practical review therefore includes search and filtering, product information, account creation, authentication, cart, delivery choice, payment, error recovery, order confirmation, and withdrawal and support routes.
An accessible marketing page followed by an unusable payment step is not an accessible e-commerce service.
Third-party technology creates a control question. The directive excludes some third-party content that is neither funded, developed nor controlled by the economic operator. That wording should not be treated as a blanket exemption for every embedded widget selected and configured by the site owner. Record what you choose, what you can configure, the vendor’s evidence and the alternative route.
Accessibility belongs to the complete customer task, not the page where the audit tool happened to run.
WCAG 2.2 is useful, but do not misstate the law
WCAG 2.2 is a W3C Recommendation organised around perceivable, operable, understandable and robust content. It gives testable success criteria for web content.
The Act does not simply say that every in-scope site must display a “WCAG 2.2 AA” certificate. EU harmonised standards and national measures matter to the presumption-of-conformity route. At the date of writing, ETSI lists EN 301 549 V4.1.0 as on approval, while version 3.2.1 remains a published standard cited for the Web Accessibility Directive. Do not claim a final harmonised standard status without checking the current Official Journal.
Use WCAG 2.2 AA as a strong engineering and design baseline, then map the service against the directive, applicable standards and national law. That distinction prevents two bad outcomes: passing an automated scan and assuming the legal work is complete, or waiting for perfect standards certainty while known customer barriers remain.
Automated testing finds only part of the problem
WebAIM’s scan detected an average of 56.1 errors per page in 2026, and low-contrast text appeared on 83.9 percent of home pages. Those figures come from machine-detectable checks at scale.
Automation is good at missing alternative text, contrast calculations, missing form labels, empty links and buttons, some heading and landmark problems, and some invalid ARIA use.
It cannot reliably decide whether alternative text communicates the right information, whether focus order matches the task, whether an error message helps recovery, whether a screen-reader announcement occurs at the right time, whether a product configurator is understandable, or whether the checkout works under zoom and reflow.
Combine automated checks with keyboard testing, screen-reader testing, zoom, high contrast, motion preferences and representative user tasks.
Fix the purchase path first
Inventory every template and component, then prioritise by customer consequence: navigation and search, product and service selection, forms and validation, authentication, cart and checkout, payment, confirmation and support.
Fix shared components before isolated pages. One corrected input component can remove the same failure from registration, delivery, billing and contact forms.
For each finding, record the affected task, the success criterion or legal requirement, severity, users affected, component owner, fix, verification method and regression test.
Do not use an overlay as a substitute for correcting the underlying interface. A preference widget may offer useful controls, but it cannot repair unlabeled fields, broken focus management or an inaccessible third-party payment flow by itself.
Publish the required service information
Service providers must make information available explaining how the service meets the accessibility requirements. Annex V specifies that this information should describe the applicable requirements, cover the design and operation of the service in accessible form, and include descriptions and explanations needed to understand operation.
Treat the accessibility statement as an operational record: service covered, standard and method used, known limitations, alternative routes, contact and feedback method, review date, remediation ownership.
Do not publish a generic statement copied from another site. If a limitation is known, name the affected task and the available alternative.
The directive requires Member States to establish enforcement arrangements and penalties. The exact authority, procedure and remedy depend on national transposition. A site serving several EU markets needs a legal review of the applicable implementations, not only the directive text.
Procurement is part of compliance
Accessibility failures often enter through purchased components. Before selecting a commerce theme, booking system, payment interface, chat tool or consent platform, ask for accessibility conformance documentation, tested versions, known exceptions, keyboard and screen-reader evidence, remediation commitments, support response time, and notification when accessibility changes.
Test the product yourself. A vendor statement is evidence to review, not a substitute for acceptance testing in your configuration.
Write accessibility requirements into procurement and release criteria. Otherwise the team pays to correct the same barrier after every platform change.
Make accessibility a release condition
Add a small gate to every release: keyboard completion of the changed task, visible focus, correct labels, names and roles, error identification and recovery, zoom and reflow, contrast, alternative text, screen-reader announcement for dynamic changes, and reduced-motion behaviour where relevant.
Keep regression tests for critical flows. Manual checks still matter, but repeatable automated tests stop known failures from returning silently.
The business case does not need an invented conversion statistic. If a customer cannot select a product, authenticate, pay or request support, the service has lost a usable transaction. The performance consequence is inside the task.
How we handle this
Origin builds accessibility into hierarchy, components, copy and interaction states before visual approval, which is the same discipline as writing a design system that survives a media budget: the contrast rule belongs in the system, not in a late audit.
Merch follows the complete commerce route, including product information, checkout, payment and after-sale support. Scale prevents paid traffic being sent into a customer path with known access barriers.
Tell us the service, the markets and the platform and we will map scope before anyone promises compliance.
Sources
EUR-Lex, Directive (EU) 2019/882.
European Commission, European Accessibility Act overview.
W3C, Web Content Accessibility Guidelines 2.2.
WebAIM, The WebAIM Million 2026.
ETSI, EN 301 549 work item.
Sources and EU-level status checked 30 July 2026. National scope, exemptions, enforcement and applicable standards require market-specific confirmation.
