Key insight: When Chrome logs "Blocked aria-hidden on an element because its descendant retained focus", it isn't being pedantic. It's telling you that a keyboard user's focus is currently trapped inside content you just told screen readers doesn't exist. That's not a lint warning—it's a live accessibility failure, and most of the fixes floating around StackOverflow just hide the symptom.
Why the popular fixes don't work
Search for this warning and you'll find advice like: remove aria-hidden from the parent, toggle it back to false, wrap it in a setTimeout, or just silence the console message entirely. None of these address the actual bug, which is a sequencing problem: you're hiding an element from assistive tech before moving focus out of it.
1// The anti-pattern that triggers the warning
2function closeModal() {
3 modal.setAttribute('aria-hidden', 'true'); // focus is still inside!
4 modal.classList.add('hidden');
5}Even if you remove aria-hidden from the modal, you haven't solved anything—you've just stopped the browser from telling you your focus management is broken. A screen reader user who tabs into that "hidden" modal will still find themselves in a confusing, mismatched state between what's rendered and what's announced.
<> A focused element, or any ancestor of it, must never be hidden from assistive technology witharia-hidden="true". If it can receive focus, it must remain exposed until focus moves away./>
The actual fix: sequence matters
The correct pattern is almost always the same, whether you're building a modal, drawer, or dropdown:
1. Move focus first, then hide.
2. Restore focus to a sensible trigger when closing.
3. Use `inert` instead of (or alongside) aria-hidden for anything that should be both invisible to AT and unreachable by keyboard/tab.
1function closeModal() {
2 // 1. Move focus out BEFORE hiding
3 triggerButton.focus();
4
5 // 2. Now it's safe to hide
6 modal.setAttribute('aria-hidden', 'true');
7 modal.classList.add('hidden');
8}For background content that should be fully disabled while a modal is open—rather than just visually hidden—inert is the better primitive:
1<body>
2 <main inert>
3 <!-- entire page background: unfocusable, unclickable, hidden from AT -->
4 </main>
5 <div role="dialog" aria-modal="true">
6 <!-- modal content -->
7 </div>
8</body>inert handles both the visual/interaction layer and the accessibility layer in one attribute, which is exactly why it eliminates this entire class of bug. aria-hidden only ever touched the accessibility tree—it was never designed to also disable focus, which is precisely the mismatch that produces the warning in the first place.
Why this keeps happening in real codebases
Most teams don't hit this because they're careless—they hit it because component libraries and CSS frameworks toggle `aria-hidden` reactively, often driven by state changes that don't know or care where focus currently lives. A dropdown closes on outside click, a modal unmounts on route change, an accordion collapses on a timer—all of these can yank visibility out from under a focused element without anyone explicitly writing bad code.
This is why auditing third-party UI components matters. If you're using a modal library and seeing this warning, don't reach for a workaround in your own code first—check whether the library itself is hiding content before restoring focus. Some libraries have gotten this wrong for years because the browser only recently (2022–2023 era Chromium updates) started surfacing it loudly enough to notice.
Practical checklist
- Never set
aria-hidden="true"on an element or its ancestor while focus is inside it. - Always move focus before hiding, and restore it after revealing.
- Prefer
inertfor anything meant to be both non-interactive and inaccessible—background overlays, closed accordions, off-screen drawers. - Trap focus inside modals while they're open; return it to the trigger on close.
- Treat the console warning as a failing test, not noise to suppress. If you can reproduce it, there's a genuine keyboard/screen-reader bug underneath.
Why this matters: This warning is one of the few places where the browser is doing real accessibility QA for you, for free, in development. Suppressing it doesn't make your app more accessible—it just makes the bug invisible to you while it stays fully visible (or rather, fully confusing) to anyone using a screen reader. If your team treats this warning the way you'd treat a failing unit test—something to fix at the root, not silence—you'll end up with modal, dropdown, and drawer patterns that are genuinely robust instead of ones that merely pass a casual glance in Chrome DevTools.
