Skip to content
wcagc
←Back to blog
EAAEN 301 549accessibility-statement

How to become EAA compliant: a step-by-step guide

A step-by-step guide to becoming EAA compliant: confirm scope, meet EN 301 549 (WCAG 2.1 AA), test in two layers, publish a statement.

P

Pavel Charkasau

To become EAA compliant, work through five steps in order: confirm the law applies to you, set your technical target, fix the accessibility problems in your code, test in two layers, and publish an accessibility statement that documents what you did. The European Accessibility Act (Directive (EU) 2019/882) has applied to new products and services since 28 June 2025, so this is a live obligation, not a future one (European Commission). The technical bar is the harmonised standard EN 301 549, which currently incorporates WCAG 2.1 Level AA. No single tool gets you there. A scanner clears the machine-detectable defects fast; a person has to check the rest before you can claim your service conforms. Any vendor promising instant compliance from a script is making a claim regulators have already fined. Here is the honest path, step by step.

Does the EAA apply to my business?

Start here, because the rest only matters if you are in scope. The EAA covers a defined list of consumer-facing products and services. On the web, the services most often caught are e-commerce, consumer banking, e-books and reading software, electronic communications, passenger transport sites and apps, and access to audiovisual media services (Directive (EU) 2019/882, Article 2).

Two things trip people up. First, location does not exempt you: if you sell into the EU market, a company based in the US or the UK is still covered. Second, there is a microenterprise carve-out, but only for services. A business that provides a service, employs fewer than 10 people, and has an annual turnover or balance sheet total of €2 million or less falls outside the service obligations (Directive (EU) 2019/882, Article 4(5) and Recital 70). Both conditions have to be true. Cross either threshold and the exemption is gone.

So the first task is a yes/no answer: consumer-facing service aimed at the EU, above the microenterprise line? If yes, you are in, and the steps below apply to you.

What standard do I actually have to meet?

The EAA sets the goal in Annex I: the service has to be perceivable, operable, understandable, and robust. It does not list the individual checks. For those it relies on the harmonised standard EN 301 549. Meet the relevant parts and you get a "presumption of conformity" with the EAA's requirements (European Commission).

The version that carries legal weight is EN 301 549 v3.2.1, and its web chapter incorporates WCAG 2.1 Level AA. In practice, "how do I become EAA compliant" reduces to a concrete engineering target: meet WCAG 2.1 AA, plus the extra EN 301 549 clauses specific to your service (things like the accessibility of support documentation).

A newer draft, v4.1.0, appeared in November 2025 and updates the reference to WCAG 2.2. Once it is finalised as v4.1.1 and cited in the Official Journal (expected during 2026), it becomes the legal bar. Until then, only a standard referenced in the Official Journal has legal effect, so WCAG 2.1 AA is what you are held to today (European Commission). My advice: build to 2.1 AA now, and read the six new 2.2 criteria at A and AA (focus not obscured, target size, dragging alternatives, consistent help, redundant entry, accessible authentication) so the eventual switch is a small edit rather than a re-audit.

The step-by-step path to EAA compliance

Here is the sequence I would run for any in-scope service. Do them in order; skipping the scoping step is how teams end up fixing pages nobody uses.

  1. Confirm scope and pick your surfaces. You already answered the scope question above. Now list the pages and flows a real customer touches: the storefront, yes, but also login, account settings, and checkout. The barriers that draw complaints live in the journey, not the homepage.
  2. Set the target. WCAG 2.1 AA for web content, plus the EN 301 549 clauses that apply to your service. Write it down as your definition of done.
  3. Scan to find the machine-detectable defects. Run your key templates through a scanner built on a real rules engine. This clears the high-frequency problems in minutes: missing alt text, low colour contrast, form fields without labels, a missing page language, duplicate IDs, broken ARIA.
  4. Review by hand for the rest. A person tests the things no tool can judge — completing checkout with the keyboard alone, whether the focus order makes sense, whether alt text is meaningful rather than IMG_4821.jpg, whether a screen reader announces the page usefully, whether error messages actually help. Our WCAG checklist tool gives you the manual list so nothing slips.
  5. Fix in the source code, then re-test. Accessibility is a property of your HTML, ARIA, and structure. Fix it there: a <button> where you had a <div onclick>, a real <label> on the input. Then re-scan the page to confirm the change held.
  6. Document what you did. Publish an accessibility statement (next section). It records your conformance level, known gaps, and a plan to close them.

That is the whole loop. It is not glamorous, and it does not end — which is the part most guides skip.

How do I test, and what can automation actually catch?

Two layers, because neither covers the whole standard on its own.

Automated testing is fast and cheap, and it is genuinely good at the defects it can see. But it sees a minority of the picture. Deque's analysis of more than 2,000 audits across roughly 300,000 issues found automated testing identified about 57% of issues by volume; counted by share of WCAG success criteria, the figure is closer to 30% (Deque, 2021). Either way, a large slice of conformance only appears under human review.

I say this as someone who builds a scanner: our tool will not catch every barrier on your site, and I would not trust one that claimed it did. The honest order of operations is scan first to clear the obvious defects, then run a structured manual pass against the criteria a machine cannot test. Use each layer for what it is good at.

What goes in the accessibility statement?

For an in-scope service, the statement is not optional. The EAA requires service providers to explain, in the information accompanying the service, how it meets the accessibility requirements — set out in the directive's Annex V (Directive (EU) 2019/882, Annex V). This is the point where EAA conformance differs from a plain WCAG audit: WCAG is a technical standard and requires no document, while the EAA does.

A useful statement is honest. It records your conformance level, lists known limitations, gives a plan and timeline for the gaps, and offers a contact for feedback. The law asks you to document effort, not to declare a perfect score. EN 301 549 Annex C gives a clause-by-clause format for recording each requirement as met, partially met, or not met — a good backbone for the statement. You can draft one with our accessibility statement generator, and the accessibility statement guide explains what each section should hold.

How do I stay EAA compliant after launch?

Conformance is a state your site drifts out of every time you ship. A new marketing template, a redesigned checkout, a third-party widget — any of them can reintroduce a barrier you already fixed. So treat compliance as a schedule, not a project. Re-scan key templates on a regular cadence, fold an accessibility check into your release process, and keep the statement current as you close gaps. A one-time pass gets you to launch; a routine keeps you there.

Frequently asked questions

How long does it take to become EAA compliant?

It depends on the size of the site and the state of the code, so any fixed number would be guesswork. A small, well-built site might clear its automated defects in days and finish the manual review in a couple of weeks. A large site with legacy templates takes longer. The realistic milestone is not "done" but "scanned, manually reviewed, fixed, and documented, with a schedule to keep it that way."

Do I need an accessibility statement to be EAA compliant?

Yes, if your service is in scope. Providers must explain how the service meets the accessibility requirements, per the directive's Annex V. The statement documents your conformance level, known gaps, and a plan to fix them.

Which WCAG version does the EAA require right now?

WCAG 2.1 Level AA. The harmonised standard EN 301 549 v3.2.1 incorporates 2.1 AA. A v4.1.1 update referencing WCAG 2.2 is expected to be cited in the Official Journal during 2026; until then, 2.1 AA is the legal bar.

Can a scanner or overlay make my site EAA compliant on its own?

No. Automation finds a portion of the issues and points you at the code; the rest needs human review. In April 2025 the US FTC finalised an order requiring the overlay vendor accessiBe to pay $1 million over claims that its product could make any site WCAG compliant (FTC, April 2025). Use tools for what they do well, and don't outsource conformance to a script.

Does the EAA apply to companies outside the EU?

Yes. If you offer covered products or services to consumers in the EU, the directive applies regardless of where your company is based.

See where your site stands today

The fastest way to turn "how do I become EAA compliant" into a plan is to look at your actual issues. Run a free scan to clear the machine-detectable defects on your key pages, then work the manual checklist for the rest. You will know what to fix, in what order, and what to put in your statement.

Pavel Charkasau, founder, wcagc.com. Last updated 27 July 2026.

Sources