Solutions
The EAA accessibility deadline is here — is my website at risk?
The European Accessibility Act is now enforceable. If your site sells products or digital services to EU consumers, accessibility is no longer only a UX improvement — it is a compliance and business risk. The fix is not an overlay widget. It is accessible code, forms, navigation and content.
The European Accessibility Act has been enforceable since 28 June 2025, and it changed accessibility from a nice-to-have into a legal expectation for a large part of the web. If your website or online store sells products or digital services to consumers in the EU — e-commerce, banking, ticketing, e-books, many SaaS products — you are likely in scope. Exact obligations depend on your sector, your size and how each member state has transposed the directive, and I don't give legal advice, but the direction is clear: the baseline for a customer-facing site is now WCAG 2.1 AA, the standard referenced by EN 301 549.
The tempting shortcut is an accessibility overlay — a widget you drop in that promises instant compliance. It doesn't deliver it. Overlays sit on top of broken markup instead of fixing it, they routinely fail with real screen readers and keyboard users, and they have themselves become a common trigger for complaints. Genuine compliance comes from the code underneath: semantic HTML, a working keyboard path, visible focus, sufficient contrast, correct ARIA and properly labelled forms. That is repairable, and it is exactly the kind of work I do in the product itself.
01 / Analysis
Signs this sounds like you
- 01Your website or online store serves consumers in the EU
- 02Keyboard navigation is broken or invisible on key pages
- 03Forms, checkout, menus or modals are hard to use without a mouse
- 04You do not have an accessibility statement or WCAG evidence
02 / Analysis
Why it happens
- 01Accessibility was never part of the original build or design QA
- 02Automated checks catch only part of the problem and miss real user flows
- 03Old components use divs, overlays or ARIA incorrectly
- 04Teams rely on plugins instead of fixing markup, focus, contrast and forms
03 / Analysis
How I fix it
- 01I audit the site against WCAG 2.1 AA and EN 301 549 with practical severity scoring
- 02I prioritize the issues that affect compliance, checkout and lead generation first
- 03I fix the problems in code: semantic HTML, keyboard support, focus states, contrast, ARIA and forms
- 04I re-test the flows and prepare a clear accessibility statement
How I'd approach it
I start with a real audit, not an automated scan. I test the site against WCAG 2.1 AA and EN 301 549 the way people actually use it — with a keyboard, with a screen reader and with automated tooling to catch the rest — and I score every issue by severity and business impact. Automated checks alone catch only a fraction of the problems, so I put the emphasis on the flows that matter: the pages that carry your compliance exposure, the checkout, and the forms that generate your leads. You get a prioritized list, not a raw dump of warnings.
Then I fix the issues in code rather than papering over them. That means semantic HTML, a complete keyboard path, visible focus states, sufficient colour contrast, correct ARIA and properly labelled forms — the foundations an overlay can never provide. I re-test each flow after the changes to confirm it works for real assistive technology, and I help you prepare an accessibility statement that reflects what was actually done. The remediation lives in your product, so it keeps working as the site grows instead of depending on a widget.
The outcome
A site that is easier to use, closer to EAA compliance and less exposed to complaints or rushed emergency fixes — with the changes implemented in the product, not hidden behind a widget.
Proof from related work
The European Accessibility Act is now enforceable. If your site sells products or digital services to EU consumers, accessibility is no longer only a UX improvement — it is a compliance and business risk. The fix is not an overlay widget. It is accessible code, forms, navigation and content.
Common questions
Does the EAA actually apply to my business?
If you sell products or digital services to consumers in the EU, it very likely does — the Act covers areas like e-commerce, banking, ticketing, e-books and many digital services. There are carve-outs, and the details depend on your sector, your company size and how your member state transposed the directive. I can tell you where your site stands against the technical standard, but for a definitive legal reading of your obligations you should also confirm with a qualified adviser.
Isn't an accessibility overlay or plugin enough?
No. Overlays sit on top of your existing markup and try to patch it at runtime, which routinely breaks for real screen reader and keyboard users and leaves the underlying issues in place. They have also become a frequent target of accessibility complaints rather than a shield against them. Real compliance comes from fixing the code — structure, keyboard support, focus, contrast and forms — which is what I do.
Do I need a full rebuild to become compliant?
Usually not. Most sites reach WCAG 2.1 AA through targeted fixes to existing markup, components and forms rather than starting over. A rebuild is only worth considering when the underlying framework or component library makes accessibility genuinely impractical, and I'll tell you plainly if that's the case instead of selling you a project you don't need.
What does the audit actually deliver?
You get a prioritized report of the accessibility issues on your key pages and flows, each scored by severity and mapped to WCAG 2.1 AA and EN 301 549, so you can see what matters most and why. It includes clear guidance on how to fix each issue and a realistic remediation plan. From there I can carry out the fixes in code and help you prepare an accessibility statement.
The service that fixes this
Web Accessibility (EAA) →Vlad Sedenko
Web Product Developer · 10+ years
I personally scope, build and ship the fix — no account managers, no hand-offs. You work directly with the developer doing the work.
LinkedIn →