· ReadyStack
Worked example
Real numbers from this tool, line by line.
Five lines in a German checkout template break EN 301 549 — and in the Irish sign-in page next door, half the findings are not law until October.
That last part is the one nobody gets right, including every chatbot I asked. The European Accessibility Act has applied to new e-commerce, banking, booking and e-book services in the EU since 28 June 2025. But the technical standard actually cited in the Official Journal — Implementing Decision (EU) 2021/1339 — is EN 301 549 V3.2.1, and V3.2.1 is WCAG 2.1 AA. Version 4.1.1, the one that folds WCAG 2.2 in, is expected to be cited around October 2026. Until then, a WCAG 2.2 criterion is good practice, not an obligation.
So a tool that reports "WCAG 2.2 failure" in September 2026 is telling you something true about accessibility and something false about your legal exposure. Those are different questions and they have different budgets.
The five lines
<html> <!-- §9.3.1.1 no lang -->
<img src="/logo.png"> <!-- §9.1.1.1 no alt -->
<div onclick="pay()">Jetzt kaufen</div> <!-- §9.2.1.1 not keyboard operable -->
<span style="color: #999">inkl. MwSt.</span> <!-- §9.1.4.3 2.85:1, AA needs 4.5:1 -->
<iframe src="/sepa"></iframe> <!-- §9.4.1.2 no title -->Fixed:
<html lang="de">
<img src="/logo.png" alt="Acme GmbH home">
<button type="button" onclick="pay()">Jetzt kaufen</button>
<span style="color: #767676">inkl. MwSt.</span> <!-- 4.54:1 -->
<iframe title="Payment form" src="/sepa"></iframe>#767676 is worth memorising: it is the lightest grey that still clears 4.5:1 on white. #777 is 4.48:1 and fails by two hundredths. Tailwind's text-gray-400 is about 2.8:1 and fails outright; text-gray-600 is 7.5:1.
What the "not yet" bucket contains
WCAG 2.2 added nine success criteria in total. Four of them are what this linter can see in markup, so they sit in its not-yet bucket — worth fixing early, but not to be reported to your compliance officer as violations today:
- §9.2.4.11 focus not obscured — a sticky header covering the focused element
- §9.2.5.8 target size — anything under 24 by 24 CSS pixels
- §9.3.3.7 redundant entry
- §9.3.3.8 accessible authentication — this is the one that catches CAPTCHAs and
onpaste="return false"on password fields
If you are shipping a sign-in page in the EU, §9.3.3.8 is the one to plan for. It is not enforceable this morning. It very likely is next year.
Where the free tools stop
axe-core and eslint-plugin-jsx-a11y are good and you should keep using them. They report WCAG success criteria. What they do not print is the EN 301 549 clause number, which is the vocabulary of the audit, the accessibility statement, and the market surveillance authority in each member state. And they do not distinguish the standard in force from the standard incoming, because from a pure accessibility standpoint that distinction does not matter — it only matters when someone asks what you are legally required to have fixed by when.
That gap is a two-column table, and that table is the extension.
The microenterprise line
One more thing the chatbots get backwards: the exemption for fewer than 10 employees and under €2 million turnover applies to services, not products. If you ship a product covered by the Act, being small does not exempt you. Check which side of that line your company is on before you decide the deadline is not yours.
15 seconds — what it actually does
Questions people ask
What does EN 301 549 Lint actually do?
It reads the markup file you have open in VS Code and flags every line that breaks one of 28 accessibility rules, printing the EN 301 549 clause number and a corrected version of the line. It also marks which findings are enforceable under the standard cited today, EN 301 549 V3.2.1, and which only arrive with V4.1.1.
Who is EN 301 549 Lint for?
EN 301 549 Lint is for front-end and full-stack developers shipping e-commerce, banking, booking, ticketing or e-book services into the European Union, where the European Accessibility Act has applied to new services since 28 June 2025. It is also for whoever writes the accessibility statement and needs clause numbers rather than generic WCAG labels.
Why is axe or eslint-plugin-jsx-a11y not enough for EU compliance?
Those tools are good and worth keeping. They report WCAG success criteria, not EN 301 549 clause numbers, which is the vocabulary an EU auditor and a market surveillance authority use. They also treat WCAG 2.2 as current, while the standard cited in the Official Journal is still V3.2.1, which is WCAG 2.1 AA. That difference decides what you are legally required to have fixed.
What is free and what does the licence add?
Free covers the file you have open: all 28 rules, every clause number, and a corrected line for each finding, with no watermark, trial or usage counter. The $29 licence changes the scope, not the quality. It scans every template in the repository, exports a dated evidence file with file, line, clause and severity, and prints machine-readable JSON so CI can fail a build.
How does this compare to paying for an accessibility audit?
A manual WCAG audit is quoted at roughly $100 to $250 per page, and $1,250 to $2,750 for a small site, according to Accessible.org's published 2026 pricing. This extension costs $29 once. It does not replace that audit: it cannot judge focus order, keyboard traps or anything needing the page running. It removes the findings a human should never have been billed to find.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. EN 301 549 Lint — EU Accessibility Act checks the file you open against 28 rules from a rule set dated 2026-09-20, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.