The European Accessibility Act, or EAA, is now in force, and it can reach companies outside Europe. One compliance guide states that enforcement began on 28 June 2025 across all 27 EU member states. It applies to consumer-facing digital services sold to EU customers.
This guide is for product owners and founders. It explains what the law covers, which technical standard to build to, and where to start. It is engineering guidance, not legal advice.
Who the Act covers
The guide lists consumer-facing digital services such as e-commerce, online banking, travel booking, telecommunications, streaming and e-books. It says the Act applies to any business serving EU consumers, even if headquartered outside the EU.
The same guide describes limited exemptions for microenterprises, defined as fewer than 10 employees and under 2 million euros in turnover. Services already on the market have until 2030 under the transition period. Penalties differ by member state, so the exposure depends on where you sell.
The standard behind the Act
The technical benchmark is EN 301 549. The same guide says it incorporates WCAG 2.1 Level AA in its entirety for web content. So for a website, WCAG 2.1 AA is the working target.
The W3C explains that WCAG is an international technical standard, and that its success criteria are grouped into levels A, AA and AAA. It also says that content that conforms to WCAG 2.2 also conforms to WCAG 2.1 and 2.0. Building to 2.2 AA is therefore a safe choice.
The four principles
MDN summarises WCAG in four principles. Content must be perceivable, operable, understandable and robust.
People can see, hear or otherwise sense the content. Think text alternatives and contrast.
Every control works with a keyboard, mouse, touch or voice.
Content and forms are clear, and errors explain how to fix them.
Code follows web standards so assistive tools and browsers can read it.
The problems that appear most often
You do not need a long audit to find the usual faults. These show up on many sites.
- Images with no text alternative, or with useless ones such as "image".
- Low contrast between text and background, especially in grey text and buttons.
- Forms with no visible labels, or with errors shown only by colour.
- Menus and dialogs that a keyboard cannot reach or cannot leave.
- Focus that is invisible, so a keyboard user cannot see where they are.
- Custom components built from plain divs with no roles or names.
What good looks like on a real page
Take a simple sign-up form. Every field has a visible label tied to the input. The tab key moves through fields in a logical order, and the focus ring is clear. An error says what went wrong and how to fix it, in text, not only in red. The submit button has a name that makes sense when read aloud.
None of this is expensive when it is designed in from the start. It becomes expensive when each page is patched one by one. That is why the work belongs in the design system, where one fix spreads to every page.
Questions to ask an agency or vendor
- Which WCAG version and level do you build to, and how do you check it?
- Do you test with a keyboard and a screen reader, or only with a scanner?
- Are accessibility checks part of your release process?
- Can you show how your components handle focus, labels and errors?
Clear answers are a good sign. Vague ones are a warning.
A practical plan
- 1ScopeList the pages and flows customers use to buy or sign up
- 2ScanRun an automated checker on key pages
- 3Test by handKeyboard only, then a screen reader
- 4Fix in the design systemRepair shared components once
- 5GuardAdd accessibility checks to every release
Start with the flows that earn money: the home page, product or service pages, sign-up, checkout and contact. Fix shared components first, such as buttons, form fields and navigation, because one repair then improves every page that uses them.
Automated tools help but are not enough. They find missing labels and contrast failures. They cannot tell whether the focus order makes sense, or whether an error message is clear. Keyboard and screen reader checks fill that gap.
Make it part of delivery
Accessibility that is added once decays with each release. Put checks in your pipeline and add accessibility criteria to your definition of done. That is cheaper than a rebuild after a complaint.
Mistakes that waste time
- Buying an overlay and calling it done. A script added on top of a page does not fix broken code underneath. Fix the source.
- Testing only one page. Accessibility faults live in shared components, so test the components and the main flows.
- Treating it as a one-off. New features add new faults. Keep checks in every release.
- Skipping people. Tools cannot replace testing with real assistive technology.
Where to start this week
Pick your most valuable page. Unplug the mouse and complete the main task with the keyboard alone. Write down every place you got lost or stuck. That short list is the start of your backlog, and it costs nothing.
How XOSOFT approaches it
Our frontend and UI/UX practice includes design systems, frontend engineering and WCAG AA accessibility. Our QA and testing practice adds automated and manual checks before release.
If you want a clear list of what to fix on your site, ask for a Discovery Sprint or book a technical call. It is a conversation with engineers, not a sales pitch.
Frequently asked questions
Does the European Accessibility Act apply to a company outside the EU?
It can. One compliance guide states that it applies to any business serving EU consumers, even if the business is headquartered outside the EU. Check with a legal adviser whether your product or service is in scope.
Which standard should a website meet?
The referenced standard is EN 301 549, which includes WCAG 2.1 Level AA for web content. Teams usually target WCAG 2.1 AA or 2.2 AA, since 2.2 content also conforms to 2.1.
Can automated tools find all accessibility problems?
No. Automated checks catch many issues, such as missing labels and low contrast, but they cannot judge things like a logical focus order or clear wording. Pair them with keyboard and screen reader testing.
Is this legal advice?
No. This article is engineering guidance. Ask a qualified lawyer about your legal duties in each country where you sell.
Need help with frontend and UI/UX?
Talk to the engineers who would do the work. We reply within one working day.