How to Check if Your Website Is EAA Compliant

"Are we EAA compliant?" is a question a lot of teams can't answer confidently, because there's no single test you run once and pass. Compliance with the European Accessibility Act means meeting WCAG 2.1 AA via EN 301 549, on an ongoing basis, across every page and flow a customer actually uses. Here's a practical process for finding out where you stand and closing the gap.

Automated scan first

Start with an automated accessibility scan — it's the fastest way to find the majority of technical issues and get a baseline you can measure improvement against.

1. Scan your highest-traffic and highest-risk pages first: homepage, product or category pages, cart/checkout, account creation and login, and any legally required pages (terms, privacy, contact).
2. Use a scanner that checks against WCAG 2.1 AA specifically, not a generic "accessibility score" — the EAA's legal reference point is WCAG 2.1 AA via EN 301 549, so that's what you need evidence against. Accessvera's free scan runs this check in about 30 seconds and returns a prioritised list of what's failing and why.
3. Re-scan after every significant redesign or new feature, not just once a year — automated scanning is cheap enough to run continuously, and new code is where new issues creep in.

Automated tools reliably catch things like missing alt text, insufficient colour contrast, missing form labels, and invalid or duplicate IDs. They typically catch somewhere between a third and half of all WCAG issues — a strong start, but not the whole picture.

Manual checks automation misses

No automated tool can judge whether an interaction actually makes sense to a keyboard or screen reader user. These checks need a human, but they don't need a specialist — a member of your own team can do them in an afternoon.

• Keyboard-only walkthrough: unplug your mouse and complete your most important user flow, usually checkout or sign-up, using only Tab, Shift+Tab, Enter, and arrow keys. Note anywhere you get stuck or lose track of where focus is.
• Screen reader spot check: turn on VoiceOver (Mac, built in) or NVDA (Windows, free) and listen to your homepage and one core flow. Does it make sense out loud? Are buttons announced as buttons, not "clickable div"?
• Zoom test: set your browser to 200% zoom and check that text doesn't get clipped, overlapping, or cut off.
• Form review: check every input has a real, associated <label>, and that validation errors are announced in text near the field, not just shown as a red border.
• Alt text quality review: automated tools confirm alt text exists; only a human can confirm it's actually accurate and useful. Compare our full WCAG 2.1 AA checklist against your findings to make sure nothing's missed.

Prioritising fixes

Once you have a combined list from automated and manual testing, you'll usually have more issues than time. Prioritise by impact:

1. Blockers first — anything that prevents a keyboard or screen reader user from completing checkout, sign-up, login, or a legally required action. These are also the issues most likely to trigger a complaint.
2. High-traffic pages next — the same contrast issue on your homepage matters more than the identical issue on a rarely-visited legal page, purely by exposure.
3. Systemic issues over one-offs — a missing focus style in your shared button component fixes dozens of instances at once; a single missing alt text fixes one.
4. Cosmetic-only issues last — anything that doesn't block a task or misinform a user, such as minor contrast on decorative elements, can wait.

This is also the point to check your exposure if you're past the deadline — see EAA deadline & penalties: what businesses must know for what enforcement looks like and how urgently you should move.

Documenting conformance

Fixing issues is only half the job — you also need a record showing you tested for and addressed accessibility, since that record is what protects you if a regulator, customer, or partner asks about compliance.

A workable, low-overhead documentation set includes:

• Dated scan reports from each automated check, kept as a simple archive.
• Notes from manual testing sessions — what was tested, by whom, and what was found.
• A changelog or ticket trail showing issues were tracked and closed, not just discovered.
• A public accessibility statement on your site describing your conformance target (WCAG 2.1 AA / EN 301 549), known limitations, and a contact method for reporting issues — several EU member states expect this as standard practice.

None of this needs to be elaborate. A dated report plus a short public statement is enough for most businesses — what matters is that it exists, it's current, and it's based on real testing rather than assumption. If you want a structured starting point, run a free scan to generate your first dated report, then work through the WCAG 2.1 AA checklist for anything it flags.