Software accessibility stopped being optional in the EU on 28 June 2025, when the European Accessibility Act took effect for new products and services. The technical standard is EN 301 549, which adopts WCAG Level AA as its benchmark, and penalties reach €100,000 or 4% of annual revenue depending on the member state. Services under contracts signed before that date have until 28 June 2027.
This guide covers what the law requires, how to audit against it, which fixes to do first, and how to keep a product accessible once it is.
Key takeaways
- The deadline has passed for new products: 28 June 2025; legacy service contracts have until 28 June 2027.
- EN 301 549 is the standard, WCAG AA the benchmark: WCAG 2.1 AA today, with 2.2 expected to be adopted as the standard updates.
- A handful of defects cause most failures: Contrast, labels, keyboard traps and missing alternatives account for the majority.
- Retrofitting costs several times more than building it in: Accessibility is a design constraint, not a testing phase.
Know what applies to you
The EAA covers products and services sold into the EU, including e-commerce, banking, transport, telecoms, e-books and consumer computing, regardless of where the supplier is based. A Turkish company selling into the EU is in scope.
Microenterprises providing services (fewer than 10 staff and under €2m turnover) are exempt for services, though not universally for products, and national implementations vary. Confirm your position with counsel rather than inferring it, because the exemption is narrower than it first appears.
Audit against the standard, not an impression
A credible audit has three layers, and skipping the third is why some products pass a scan and still fail in use.
Automated scanning catches roughly a third of issues: contrast, missing alternative text, form labels, document structure. It is cheap, repeatable and belongs in your build pipeline.
Manual expert review covers what tooling cannot judge: whether alternative text is meaningful, whether focus order matches the visual order, whether an error message actually explains the problem.
Assistive technology testing means operating the product with a screen reader and by keyboard alone. This is where the real failures appear, and it is the layer most often skipped.
Budget two to three days for a thorough audit of a complex product, plus three to five days of remediation for a typical set of findings.
Fix these first
| Issue | Why it matters | Typical effort |
|---|---|---|
| Colour contrast below 4.5:1 | Affects the largest number of users; trivially detectable | Low, a palette change |
| Missing form labels | Makes a form unusable with a screen reader | Low |
| Keyboard traps | Strands a keyboard user with no escape | Low to medium |
| No visible focus indicator | Keyboard navigation becomes guesswork | Low |
| Images without alternatives | Content simply does not exist for some users | Low, but volume adds up |
| Inaccessible custom components | Bespoke dropdowns and modals are the usual culprits | High |
The first five are cheap and cover a large share of both real-world impact and audit findings. The last is where most of the remediation budget goes, and it is the argument for using standard components rather than building your own.
Build it in rather than bolting it on
Retrofitting accessibility into a finished product costs several times more than designing for it, because the fixes touch markup, styling, component behaviour and sometimes the interaction model itself.
The practical measures: choose an accessible component library rather than hand-building interactive controls, put automated checks in the pipeline so regressions fail the build, include keyboard operation in your definition of done, and write acceptance criteria that mention it.
Design decisions matter as much as code. Contrast, target size, and not relying on colour alone to convey meaning are settled in the design file, and fixing them there costs nothing.
Publish an accessibility statement
The EAA expects suppliers to document conformance. An accessibility statement should describe the standard you conform to, the known limitations, the date of the last assessment, and how someone reports a problem.
Publishing known gaps is not an admission of failure; it is what the regulation asks for, and a statement claiming full conformance that a user disproves in a minute is worse than an honest one.
Keep it accessible
Accessibility regresses with every release unless something prevents it. Add automated checks to continuous integration, include keyboard and screen-reader testing in the release checklist for changed screens, and re-audit annually or after any significant redesign.
Assign an owner. Accessibility that belongs to everyone belongs to nobody, and the standard itself will move, EN 301 549 is expected to update to WCAG 2.2 as the European standard is revised.
The case beyond compliance
Roughly one in four adults in the EU has some form of disability, and accessible products are measurably easier for everyone else: captions get used in noisy environments, keyboard navigation suits power users, and clear error messages reduce support contact.
Accessibility work also tends to improve the things that correlate with search performance: semantic structure, meaningful headings, descriptive links and page performance. It is the rare compliance requirement that pays for itself in ordinary product quality.
Related guides
- If the budget conversation comes first, start with AI Workflow Automation: Use Cases, Risks, and Roadmap.
- There is a longer treatment of the same subject in Admin Dashboard Development: Features, Architecture, and Cost Drivers.
When the legacy problems in Software Accessibility: Audit, Priorities, and Remediation need a sequenced plan, Discuss Your Modernization Plan.
Ali Boran Gazel