The accessibility deadline that applies to where your users are
The European Accessibility Act reaches any business selling digital services to EU consumers, wherever it is headquartered. It has applied since June 2025, and 2026 is the first full year of supervision.
There is a pattern in how software regulation reaches companies outside the jurisdiction that wrote it. It does not arrive as a letter from a regulator. It arrives as a clause in a client contract, or as a procurement questionnaire you have three days to answer.
The European Accessibility Act is now at that stage.
What changed and when
The Act has applied since 28 June 2025, when accessibility requirements began covering new products and newly published digital content. What has changed is supervision: member states have transposed it into national law, and 2026 is the first full year in which national authorities are supervising against it.
Enforcement sits at member-state level, so penalties vary by country, and I have not found a reliable consolidated schedule of them — treat any single figure you see quoted with suspicion. The mechanism that should concern you is not the fine anyway. It is that a user who cannot complete a purchase can file a complaint, and those cases are public.
The scope is the part people get wrong
The Act applies to websites and digital services sold to consumers in any EU member state, regardless of where the business is headquartered. The geographic location of the company is irrelevant if it serves EU customers.
If you run an e-commerce storefront, a banking or payments interface, a transport booking flow, or a digital content service, and any of your customers are in the EU, you are in scope. Being registered in Kathmandu, Lagos or Toronto does not remove you from it. Selling through a client who is in the EU does not remove you either — it simply means the obligation arrives via their compliance team rather than directly.
What is actually required
The standard is WCAG 2.1 Level AA. In practice, for a typical web product, the criteria that catch teams out are consistent and mostly unglamorous:
Colour contrast ratios that hold across your whole palette, not just body text. Full keyboard operability — every interactive control reachable and usable without a mouse, with a visible focus state. Descriptive headings and link text, so that "click here" and "read more" stop being acceptable. Form validation that announces errors rather than only colouring a border red. Responsive layouts that survive zoom and reflow.
None of that is exotic. Most of it is what a careful front-end engineer would do anyway. The reason it becomes a project is that it is far cheaper to build in than to retrofit, and retrofitting is what most teams are now doing.
Why this is worth doing before you are asked
Two arguments, one defensive and one not.
The defensive one: an accessibility questionnaire from an EU client is a fast, hard qualifier. A team that can answer it with a real audit and a remediation plan wins work from teams that cannot. Being able to say "we build to WCAG 2.1 AA and here is our conformance statement" is a commercial asset, not a compliance cost.
The other argument is more straightforward. Contrast minimums, keyboard access and clear error messaging make products better for everyone, on cheap devices, in bright sunlight, on flaky connections, for users who are tired or in a hurry. The overlap between accessibility work and general interface quality is very large. It is one of the few regulatory regimes where doing the thing properly and doing the thing minimally point in almost the same direction.
Where to start
Run an automated pass first, because it is free and it will find the contrast failures and missing labels. Then do the two things automation cannot: unplug your mouse and complete your product's primary flow with the keyboard alone, and read your own error messages aloud without looking at the screen. Those two exercises find more real problems in an hour than a scanner finds in a week.
Then write down what you found and what you plan to do about it. A dated, honest remediation plan is worth more in a procurement conversation than a clean scanner report, because everyone in that conversation knows the scanner does not catch most of it.
The deadline passed over a year ago and this is the first full year of supervision. The useful question is no longer whether this applies to you, but whether you find out from your own audit or from a client's procurement team.
Building something like this?
We are a product studio in Kathmandu. Tell us what you are building and an engineer will reply.