The European Accessibility Act did not create a single finish line for every digital product. It created requirements for defined products and services, national systems for enforcement and continuing responsibilities for organisations in scope.
Directive (EU) 2019/882 has applied since 28 June 2025. One year on, the practical lesson is that accessibility must be an ongoing part of product work, not a project organised around one date.
- 17 April 2019
The Directive is adopted. - 28 June 2022
Deadline for Member States to transpose it. - 28 June 2025
The applicable requirements begin to apply. - 28 June 2026
One year of implementation and maintenance.
Start with scope
The Directive covers selected products and services, including consumer computer systems, payment and certain self-service terminals, electronic communications, access to audiovisual services, elements of passenger transport, consumer banking, e-books and e-commerce.
Not every organisation is treated identically. The text includes transition provisions in Article 32, an exemption for microenterprises providing services and a documented process for assessing fundamental alteration or disproportionate burden.
These are legal questions depending on the product, service, Member State and operating model. A generic website scan cannot answer them. Teams should document what they provide, which requirements apply and who owns the decision.
The deadline began an operating period
Services in scope must be designed and provided according to the applicable requirements. Providers must also prepare information explaining how the service meets them and keep it available while the service operates.
Member States check compliance, follow complaints, verify remediation and define penalties in national law. Details therefore vary between countries within the shared European framework.
Products can regress after a successful audit. Releases, third-party components, content and design-system changes can reintroduce barriers. Conformity is not frozen on the date of a report.
EAA, standards and WCAG
The Directive contains functional requirements and provides a route for referenced harmonised standards or technical specifications to create a presumption of conformity for what they cover.
EN 301 549 is a European ICT accessibility standard. Its web clauses incorporate WCAG 2.2 requirements and it covers areas beyond ordinary web-content testing.
WCAG remains essential engineering guidance, but passing an automated WCAG scan is not a complete legal analysis. Automation does not determine scope, documentation, accessible support or whether an exception is justified.
A safer workflow is to determine scope with appropriate expertise, map requirements to journeys and components, use standards as engineering references, combine automated and manual testing, and keep evidence and remediation current.
- European Accessibility Act requirements
- Referenced harmonised standards or technical specifications
- EN 301 549, whose web clauses incorporate WCAG requirements
WCAG is essential for web implementation, but it does not by itself determine the Directive’s scope or cover every legal and product requirement.
What teams should maintain
Design
Define keyboard behaviour, focus, errors, reflow, targets, contrast and alternatives before implementation.
Engineering
Run fast checks in CI and retain manual keyboard and assistive-technology testing for relevant changes.
Product
Maintain an accessibility backlog with owners and connect public feedback to product triage.
Leadership and procurement
Fund remediation as product work and test third-party integrations in their real context.
Useful evidence includes a documented scope decision, critical journeys, automated results linked to builds, manual test notes, known issues and owners, component tests, user feedback and up-to-date public information about the accessibility of the service.
The next year
The stronger question is not whether an organisation can claim a permanent label of compliance. It is whether it can discover barriers, prioritise them, fix them and demonstrate that the improvement survives future releases.
That capability produces clearer interfaces, more dependable components and products that work for more people.