Two things happened that most teams have filed under "later", and one of them has a date attached that has already passed.
The European Accessibility Act took effect in June 2025. It is no longer a future deadline for anyone selling into the EU; it is a fact about the present. And WebAIM's February 2026 scan of the top one million home pages detected WCAG 2 A/AA failures on 95.9 per cent of them — up from 94.8 the year before, reversing six years of small improvements.
That second number is the one I want to start with, because the direction is the interesting part.
The failure rate is going backwards
Ninety-five point nine per cent, at an average of 56.1 detected errors per page. Low-contrast text alone appeared on 83.9 per cent.
Two things about that figure deserve to be stated carefully. First, these are automatically detectable failures only. Automated tools catch a minority of WCAG criteria — the ones expressible as a rule about the DOM — and cannot evaluate whether alt text is meaningful, whether a focus order makes sense, or whether a custom widget communicates its state to a screen reader. Real conformance is therefore certainly rarer than the remaining 4.1 per cent suggests.
Second, it got worse, in a year when accessibility had more legislative attention than it has ever had. The most plausible reading is that the web is adding complex interactive interfaces faster than it is adding accessible ones, which is not a moral failing so much as a description of how component libraries get adopted.
What the EAA actually covers
The Act applies to businesses providing certain products and services in the EU — e-commerce, banking, e-books, transport ticketing and telecommunications among them — above specific size thresholds.
Many micro-enterprises are exempt for services. The exemptions are narrower for products. That asymmetry is the part people get wrong, and it is specific enough that "we are small, so we are fine" is a guess rather than a position. Check where you actually sit rather than which half of the sentence you remember.
Enforcement mechanisms vary by member state. They generally include the ability for regulators to investigate complaints and require remediation, with penalties attached in some jurisdictions. The commercial cost runs alongside the legal one and is more immediate: customers using assistive technology cannot buy from a site they cannot operate, and they do not file a complaint about it. They leave.
What WCAG 2.2 AA asks for, in practice
Four principles. Content must be perceivable — text alternatives, sufficient contrast. Operable — full keyboard access, no traps. Understandable — predictable navigation, clear error messages. Robust — works correctly with assistive technology.
WCAG 2.2 adds a handful of criteria over 2.1, and two of them will hit component code directly.
Focus Not Obscured, which means the focus indicator must not be hidden behind something else. Sticky headers and sticky footers are the usual culprits, and this is a genuinely common failure in modern layouts, because the header was designed against a scroll position rather than against a focus ring arriving from a keypress.
Target Size, at a minimum of 24 by 24 CSS pixels. Icon-only buttons in dense toolbars are where this bites, and it is worth measuring rather than eyeballing, because a 24-pixel icon in a 20-pixel hit area is a fail that looks fine.
The four component patterns that account for most of it
In practice, the failures I find in reviews cluster into the same handful of patterns, and all four come out of component libraries rather than out of page markup.
The div that listens for clicks. It is not focusable, it has no role, it does not respond to Enter or Space, and it is invisible to anything that navigates by element type. Everyone knows this one and it is still the single most common finding, because a div is what you get when you start from the visual design and add behaviour afterwards.
The custom select. Native selects are ugly and behave differently across platforms, so they get rebuilt, and the rebuild almost never reimplements the keyboard model — type-ahead, arrow navigation, Escape to close, the announcement of how many options there are and which one is active. A listbox that looks right and does not announce its state is worse than the ugly native control, because it fails silently.
The modal that does not trap focus. Open it with a keyboard and Tab straight out of it into the page behind, which is still there, still scrollable, and now has a focus ring somewhere nobody can see. The fix is well documented and the bug survives because nobody tests it with a keyboard.
And the icon-only button with no accessible name. A button containing an SVG and nothing else announces as "button", full stop. An aria-label is one attribute and it is the difference between a usable toolbar and a row of identical unlabelled controls.
None of those four is hard. All four are cheaper to get right at component-authoring time than at audit time, which is the entire argument for not deferring this.
What the scanners cannot tell you
The 95.9 per cent figure counts only what a tool can detect, and it is worth being precise about where that boundary falls, because a clean automated report gets treated as a pass.
A scanner can tell you an image has no alt attribute. It cannot tell you the alt text says "image1.png", or that it describes the photo rather than the reason the photo is on the page, or that a decorative image has a paragraph of alt text a screen-reader user now has to sit through.
It can tell you an input has no associated label. It cannot tell you the label says "Name" above a field that wants a company registration number.
It can measure contrast on solid backgrounds. It struggles with text over images, over gradients, and in any state it did not render — hover, focus, disabled, error.
And it cannot evaluate order, which is where the genuinely expensive failures live. Whether the focus sequence matches the visual sequence. Whether a live region announces the thing that changed and not the entire page. Whether the flow makes sense when you cannot see the layout that was holding it together.
That is why an automated pass is the start of the work rather than the evidence of it — and why the real conformance rate is certainly worse than 95.9 per cent suggests rather than better.
The self-check that takes twenty minutes
Unplug the mouse and navigate your own primary flow with the keyboard alone. Not the homepage — the flow that makes money. You are looking for three things: whether you can reach everything, whether you can see where you are at every step, and whether you can get back out of anything you got into.
Then run an automated scanner over your key pages and check colour contrast on the templates rather than on one page.
That will surface the obvious gaps immediately, and given the 95.9 per cent figure, assume it will surface some. For an actual conformance claim, or if the quick check turns up anything structural, manual screen-reader testing is the only way to know your real position, because it is the part the scanners cannot do.
The part worth internalising
Accessibility work has an unusual property among engineering tasks: almost all of it is also a correctness fix.
A focus indicator that survives a sticky header is a keyboard usability fix for everyone who tabs through forms. Adequate contrast is a legibility fix for anyone outdoors. Target sizes are a fix for anyone on a train. Semantic markup instead of a div listening for clicks is a fix for the browser's own behaviour, for autofill, for search, and for whatever assistive technology exists in five years that nobody is testing against today.
Which is why "we will do accessibility in a later phase" tends to be expensive rather than merely late. The later phase is a retrofit of decisions that were free to make correctly the first time.
Do not assume you are the exception. Ninety-five point nine per cent of the top million home pages are not the exception either.
Read the full version
This is the condensed version. The full article covers the exemption criteria in more detail, what a conformance claim actually requires, how audits get scoped, and the questions businesses ask when they find out the date has passed.
WCAG 2.2 and the European Accessibility Act: What Businesses Need to Know
Sources
The covered products and services, the microenterprise provisions and the 28 June 2025 application date are in Directive (EU) 2019/882. The four principles and the conformance levels are defined in WCAG 2.2, with the criteria added over 2.1 — including Focus Not Obscured and Target Size at 24 by 24 CSS pixels — listed in What's New in WCAG 2.2. The failure rates are from The WebAIM Million, 2026 report: 95.9 per cent with detected failures against 94.8 in 2025, 56.1 errors per page, low-contrast text on 83.9 per cent. The reading of what the reversal means is mine.
If you have retrofitted Focus Not Obscured across an existing design system with sticky chrome, I would like to know what you ended up doing — every solution I have seen so far trades something away, and I have not found one I like.
Top comments (1)
On your closing question: the least-bad version I've found is scroll-padding-top on the scroller, set from the same variable that sizes the header (plus scroll-padding-bottom for a sticky footer). Browsers respect it when they scroll a focused element into view, so the ring lands below the chrome instead of under it.
The trade-off is that it breaks the moment the header height stops being a single number, like a header that collapses on scroll. Then the padding is right for one state and wrong for the other. Tying both to one token at least makes that mismatch show up in a diff rather than in an audit.