Your `aria-hidden="true"` sits right there in the Elements panel, untouched. Then you switch to Chrome's Accessibility panel and the subtree you told it to hide is still there — still exposed, still fully readable, per CSS-Tricks, while focus remains inside it.
Chrome isn't warning you. It's overruling you.
That gap between the two panels is the whole bug, and most of us met it the same way. You closed a dialog, the console went that particular shade of angry mustard, you highlighted the string and dropped it into a search box.
The top results handed you a `blur()` one-liner. It made the warning disappear and, per CSS-Tricks, made a screen-reader user land silently on `<body>`, hearing silence or just the page title.
Here's what happened in that instant, named plainly: you didn't fix anything. You paid the console to stop talking.
The CSS-Tricks author who mapped this out is unusually honest about it. The warning is correct, they write — "there's a real person on the other side of it," someone whose focus is about to drop into a hole in your page. And every fix ranking above them — the `blur()`, the `setTimeout` shim, yanking `aria-hidden` off, `modal={false}` on Radix or shadcn — "quiets the console while quietly hurting the person the browser was trying to protect." They know because they shipped one too.
Every fix ranking above them quiets the console while quietly hurting the person the browser was trying to protect. They know because they shipped one too.
The real fix is one sentence: focus has to leave a region before that region becomes hidden or inert. In practice it's an order of operations — un-inert the background, move focus out, then hide the closing shell. Get it right and the result is boring, which is the point.
Get it wrong and the user hits Esc, hears silence, and has to Tab from the top of a long page back to where they were.
Hold that scene, because it is the entire industry disease in miniature. The reflex isn't ignorance. It's treating a warning as a nag to suppress rather than a user to protect — and that reflex scales.
The WebAIM Million measures the scale. In February 2026, 95.9% of the top million home pages had a detectable WCAG failure, up from 94.8%, reversing six straight years of slow improvement.
Average errors per page climbed 10.1%, to 56.1. Across the sample, that's 56,114,377 distinct barriers.
And the same six failures have caused 96% of all errors for seven consecutive years: low contrast, missing alt text, missing labels, empty links, empty buttons, missing document language. These aren't accessibility exotica. They're first-semester design fundamentals — legibility, labeling, telling a button apart from a link.
So the fixes aren't unknown. They're documented everywhere, and they've been the same for a decade. As one analyst put it flatly: this is not a knowledge problem.
WebAIM framed it as tolerance, not ignorance — "Every system is perfectly designed to get the results it gets," and this system was clearly not designed to prioritize accessibility. The barriers persist "because their impact on disabled users remains easy for so many organizations to overlook."
Now watch the same suppress-the-warning reflex get amplified by tooling. In the GAAD Foundation's AIMAC benchmark, 35 of 37 AI models — 94.59% — produce multiple critical and serious issues by default when asked to generate HTML.
Yet 88% of engineering leaders report high or very high trust in the accessibility of their AI-generated code. The same survey found 64% cite accessibility as a top driver of post-production rework, and 96% say they're already prompting their agents for accessible output.
Read those numbers together. Teams trust the output, prompt for accessibility, then rework it in production — because "we prompted the AI for accessible output" is not proof of anything.
The failure has a signature, and it's ARIA. Usage rose 27% in a single year; 82.7% of pages now use it, averaging 133.6 attributes per page.
Pages using ARIA averaged 59.1 errors versus 42.0 without it. More custom interaction, applied faster, without the contextual judgment correct use demands — machine-generated attributes layered onto components nobody fully understands.
That's the fix-culture reflex industrialized: bolt on the attribute that looks right, ship the clean-ish console, let production absorb the rest.
But suppression is only half the rot. The second incentive is quieter and worse, because it teaches teams to stop caring about semantics at all.
The exact structure that helps a screen reader is what makes a page trivial for an AI crawler to harvest. A screen reader needs to understand a page's structure; so does a crawler. A blind user benefits from meaningful image descriptions; so does a multimodal model learning to associate language with visual concepts.
This isn't abstract. LAION-5B, one of the largest public image-text datasets, paired Common Crawl images with the HTML alt text written to make them accessible — and that dataset trained Stable Diffusion and DALL·E.
The blind web, quite literally, helped teach AI how to see.
So the market now rewards the inaccessible page and punishes the compliant one. Good markup — the semantic HTML, the descriptive alt text, the honest heading structure — is exactly what turns your site into free training fodder for a system that may compete with you.
The defensive response makes it darker. Organizations reach for CAPTCHAs, rate limiting, browser verification.
In WebAIM's screen-reader survey, users have ranked CAPTCHA the single most problematic barrier on the web — ahead of ambiguous links, missing alt text, unexpected screen changes — for more than a decade. Google's own documentation admits reCAPTCHA can't guarantee accessibility for screen-reader or motor-impaired users.
Disabled users aren't the ones running large-scale scraping operations. Yet they're the ones who keep failing the tests built to stop it — casualties of a fight between publishers and AI companies they never entered.
None of this argues for inaccessibility as a defense; that would be a profoundly backward strategy, and the harms of poor accessibility are real. But it does explain the reversal. A compliance culture that already treats warnings as noise now has a market reason to treat semantics as a liability.
The number moves when the metric changes. Right now success is measured as a clean console — yellow gone, release shipped, rework deferred.
Reframe success as the person the warning names. Migrate to the native `<dialog>` element and `.showModal()`, and the browser runs the focus dance for you; this class of bug all but disappears — not as a platform-catches-up flourish, but because it serves the user by default.
Where you can't tear out the component library, choose order-of-operations over attribute-yanking. Un-inert first, move focus out, then hide.
And reject the two sentences doing the most damage right now: "it's just a warning," and "we prompted the AI for accessible output." Neither is proof. Both are the sound of paying the console to stop talking.
The warning was right. It always was. There's a real person on the other side of it, and the only fix that counts is the one they can hear.