Accessibility after the deadline: from audit to product quality
The European Accessibility Act is now in application and WCAG 2.2 is an ISO standard. Teams need an operating practice, not a one-off remediation sprint.
The European Accessibility Act entered into application on 28 June 2025 for covered products and services. In October that year, WCAG 2.2 was approved as ISO/IEC 40500:2025. Those milestones moved accessibility further into procurement, governance and product leadership.
They did not turn accessibility into a checklist.
Conformance criteria are essential because they give teams a shared, testable baseline. But a product can pass automated checks and still be exhausting to use. It can expose technically valid names to a screen reader while presenting a confusing journey. It can support keyboard input while trapping a person in an unexpected interaction.
Test the journey, not only the page
Accessibility work often fragments along organisational lines: design checks colour, engineering checks markup, content checks alternative text and quality assurance runs a scanner. Users experience the result as one journey.
Choose the high-value journeys and test them end to end: register, sign in, find a product, complete a payment, recover from an error and contact support. Include different zoom levels, reflow, keyboard-only navigation, screen readers, voice input and reduced motion where they matter.
The strongest defects frequently sit between components. A modal may be accessible in isolation but return focus to the wrong place. An error summary may work, while a timeout erases everything the person entered. A payment provider may break a journey the core team thought it had completed.
Put accessibility into product evidence
Teams improve what they make visible. Accessibility belongs in the same evidence set as reliability, conversion and security:
- acceptance criteria for consequential interactions;
- keyboard and assistive-technology checks in component review;
- automated rules in continuous integration;
- manual journey testing before release;
- a documented route for reporting and resolving barriers;
- named ownership for third-party components and content.
Automated tooling remains useful, particularly for regressions. It is a guardrail, not proof of usability. Manual inspection and testing with disabled people reveal problems a rules engine cannot understand.
Treat clear content as interface infrastructure
Plain language, descriptive headings, useful link text and predictable instructions reduce cognitive load for everyone. They also make interfaces easier for assistive technology to navigate. Content design should happen while a flow is being shaped, not after the layout is signed off.
The same is true of focus order and semantics. A polished visual can still have a broken reading order if the DOM follows a different story. Designing structure and presentation together prevents expensive reconstruction later.
Build a repeatable accessibility release gate
A proportionate gate does not need to delay every release. Define a small set of non-negotiable checks, scale the manual review with risk, and keep a transparent backlog for known issues. When a third party creates a barrier, record the limitation, press the supplier and provide an alternative route.
The objective is not a perfect audit document. It is a product that more people can use reliably, including when they are under pressure, tired, temporarily injured or using an unfamiliar device.
This article is product guidance, not legal advice. Coverage and obligations vary; obtain appropriate advice for your service and markets.