The European Accessibility Act (EAA) came into force on 28 June 2025. If your product reaches EU customers — and you ship a website, a SaaS, an e-commerce store, an e-book reader, or really anything users interact with through a screen — the EAA quietly became one of your hard requirements.
It does not matter where your company is incorporated. What matters is whether EU users can buy from or interact with your service. Fines run up to €100,000 in most member states, plus the more painful penalty: forced product withdrawal from EU markets.
This guide is the practical checklist I wish I had when I built FixMyWeb — a free WCAG scanner I now use myself to keep our own pages clean. Run through it once, and you will know exactly which 20% of changes get you to 80% conformance.
Why WCAG 2.1 AA is the practical EAA standard
The EAA directive does not literally name "WCAG 2.1 AA". It refers to EN 301 549 — the European harmonised standard for digital accessibility. EN 301 549 v3.2.1 (the version in force at EAA enforcement) explicitly adopts WCAG 2.1 Level A and AA success criteria for the "Web" chapter.
Translation: if you pass WCAG 2.1 AA on your public-facing pages, you cover ~95% of the EAA web requirements out of the box. WCAG 2.2 (published October 2023) adds 9 more criteria — adopting them now is forward-looking but not strictly required yet.
The 12-point WCAG quick-check
For every page you ship to EU users:
1. Images have meaningful alt text (WCAG 1.1.1)
<!-- Bad: -->
<img src="/hero.jpg">
<!-- Decorative: -->
<img src="/divider.svg" alt="" role="presentation">
<!-- Meaningful: -->
<img src="/dashboard.png" alt="Dashboard showing weekly accessibility score trending from 64 to 89">
alt="" is correct for purely decorative images (combined with role="presentation"). Empty alt is not "I do not care" — it is a deliberate signal to screen readers to skip the image.
2. Color contrast ≥ 4.5:1 for normal text, ≥ 3:1 for large text (WCAG 1.4.3)
Light grey on white (#999 on #fff) is 2.85:1 — fails AA. The most common offender is the "subtle hint" text under inputs and the placeholder text in forms.
Test in 30 seconds: fixmyweb.dev/tools/contrast-checker.
3. Page has a lang attribute on <html> (WCAG 3.1.1)
<html lang="en">
Without this, screen readers default to the user's OS language and mispronounce everything. One attribute, huge UX win.
4. Form inputs have programmatic labels (WCAG 3.3.2)
<!-- Bad: placeholder only -->
<input placeholder="Email">
<!-- Good: -->
<label for="signup-email">Email</label>
<input id="signup-email" type="email" placeholder="you@company.com">
<!-- Or, when visual layout forbids a label: -->
<input type="email" aria-label="Email" placeholder="you@company.com">
Placeholder text disappears the moment the user starts typing and is not announced as a label by VoiceOver / NVDA / JAWS.
5. All interactive elements are reachable by keyboard (WCAG 2.1.1)
Tab through the entire page with no mouse. Every button, link, dropdown, modal, and slider must be reachable and operable. Custom <div onClick> handlers are the #1 violator — switch to <button> or add tabindex="0" + onKeyDown for Enter/Space.
6. Focus is always visible (WCAG 2.4.7)
/* Bad — designer-requested "clean look" */
*:focus { outline: none; }
/* Good — visible focus ring with sufficient contrast */
*:focus-visible {
outline: 2px solid #4A90D9;
outline-offset: 2px;
}
:focus-visible is the modern selector — applies the ring only when the user navigated via keyboard, not on a mouse click. Best of both worlds.
7. Heading hierarchy is sequential (WCAG 1.3.1)
<h1> → <h2> → <h3>. Do not skip levels (<h1> straight to <h4>). Screen reader users navigate by headings (H key in JAWS/NVDA) — the structure literally is the page outline.
One <h1> per page is best practice, multiple are tolerated but signal layout-driven markup.
8. Skip-to-content link as first focusable element (WCAG 2.4.1)
<a href="#main-content" class="sr-only focus:not-sr-only">
Skip to main content
</a>
<header>...big navigation...</header>
<main id="main-content">...</main>
Keyboard users should not have to Tab through 40 menu items before reaching the article. The sr-only class hides visually but keeps it in the tab order; focus:not-sr-only reveals it on focus.
9. Buttons and links have accessible names (WCAG 4.1.2 / 2.4.4)
Icon-only buttons are silent killers:
<!-- Bad — screen reader announces "button" with no purpose -->
<button><svg>...</svg></button>
<!-- Good -->
<button aria-label="Close dialog">
<svg aria-hidden="true">...</svg>
</button>
The aria-hidden on the SVG prevents double-announcement.
10. Tables have headers and captions (WCAG 1.3.1)
<table>
<caption>Q4 2025 accessibility audit results</caption>
<thead>
<tr>
<th scope="col">Page</th>
<th scope="col">Score</th>
<th scope="col">Critical issues</th>
</tr>
</thead>
<tbody>...</tbody>
</table>
scope="col" / scope="row" is what makes header cells navigable in screen reader table mode.
11. Status messages use ARIA live regions (WCAG 4.1.3)
After a form submit, login, or async action — the result message must reach assistive tech:
<div role="status" aria-live="polite">
Settings saved successfully.
</div>
polite interrupts at the next pause, assertive interrupts immediately (use for errors only).
12. Viewport allows zoom (WCAG 1.4.4)
<!-- Forbidden under WCAG: -->
<meta name="viewport" content="width=device-width, user-scalable=no">
<!-- Required: -->
<meta name="viewport" content="width=device-width, initial-scale=1">
Roughly 1 in 12 men and 1 in 200 women have color vision deficiency, and 8.4% of EU residents have some form of visual impairment (Eurostat 2022). Disabling zoom locks them out of your content.
The 30-second audit
Manual review of all 12 points across a 50-page site takes a serious afternoon. The shortcut I built into FixMyWeb runs 201 automated WCAG 2.1 / 2.2 checks per page in under 60 seconds, returns a 0-100 accessibility score broken down by the four WCAG principles, and gives you copy-paste fix snippets for every issue.
# Or just use the web UI — paste any URL:
curl -X POST https://fixmyweb.dev/api/scan \
-H "Content-Type: application/json" \
-d '{"url":"https://your-site.example.com"}'
It is free for up to 3 scans per month (no signup), with paid plans starting at $9/month for higher volume + PDF export + monitoring. Lifetime deal available right now via DealMirror if you prefer a one-time payment.
What FixMyWeb does not do
A few honest disclaimers:
- Automated checks catch ~30-40% of all WCAG issues. The rest require human review (especially cognitive load, content clarity, screen reader actual user testing). Tools like FixMyWeb cover the surface — they do not replace a user research session with people who use assistive technology daily.
- Overlays are not a fix. If you have seen accessiBe / UserWay / AudioEye widgets, those overlay JavaScript on the page. They have been sued repeatedly for misleading claims and do not address WCAG conformance at source. FixMyWeb deliberately is an audit, not an overlay — you fix issues in your codebase, not behind a JS shim.
Next steps
- Run fixmyweb.dev/scan on your homepage today. Note the score and the top 3 critical issues.
- Fix the top 3 critical issues in your codebase this week.
- Re-scan. Track the score over time — it is a good leading indicator for legal exposure under EAA.
- Once your average page is above 90, generate a VPAT / ACR document for your procurement team.
The EAA deadline already passed. Treat this as the year you stop saying "we will get to accessibility next quarter" and ship the first 3 fixes today.
Disclosure: I am the founder of FixMyWeb. The tool is genuinely free for the first 3 scans/month and I dogfood it on every project I ship — but please file an issue if anything in this checklist is wrong or out of date. I want to keep this honest.
