Blocked aria-hidden: The Warning is Right, and Every Fix You’ve Found is Wrong
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
The Chrome console warning about 'blocked aria-hidden on an element because its descendant retained focus' is correct, not a nag, and every popular workaround for it — blur() with no follow-up, setTimeout delays, stripping aria-hidden, or modal={false} — actively harms screen reader users by leaving focus stranded on <body> or removing the modal focus trap entirely. The root defect is an ordering bug: code hides a region (via aria-hidden) while focus is still inside it, creating 'ghost focus' where a control is focusable but invisible to assistive tech. Chrome has quietly repaired this since around 2020, made it loud starting with Chrome 127 (open-time variant) and Chrome 131 (close-time variant), and the correct fix is a four-step teardown contract: remove inert from the background, synchronously restore focus to the trigger, apply inert (not aria-hidden) to the closing overlay so it can fade out safely, then unmount on transition end. Vanilla JS and React implementations are given, along with a table comparing native <dialog>, React Aria, Radix, Bootstrap, and Floating UI, plus edge cases (deleted triggers, stacked modals, tab-away, zero-duration transitions) and a runnable four-variant demo.
Table of contents
The fix, if you’re in a hurryChrome isn’t warning you. It’s overruling you.The four ways you get hereEvery fix that worked made it worseThe teardown contractDon’t take my word for itSo whose bug is it, really?Questions this post answers
How do I properly fix the Chrome warning about aria-hidden being blocked because a descendant retained focus?
Reorder your modal teardown so focus leaves before the region is hidden: remove inert from the background, synchronously call trigger.focus(), then apply inert (not aria-hidden) plus pointer-events: none to the closing overlay so it fades out unreachable by focus, and unmount only after transitionend or transitioncancel fires. Developers untangling modal focus bugs can track accessibility fixes like this one through daily.dev.
Why does calling blur() on close fix the aria-hidden console warning but break accessibility?
Calling document.activeElement.blur() with no follow-up sends focus nowhere, so the browser falls back to focusing the body element. This clears the console warning but strands keyboard and screen reader users, who then hear silence or the page title and must tab from the very top of the page to get back to where they were, a WCAG 2.4.3 focus-order failure. Anyone auditing modal accessibility can follow daily.dev to catch fixes that trade a clean console for a broken focus order.
When did Chrome start warning about aria-hidden blocking focus on modals?
Chrome surfaced this in two waves: the open-time variant, warning about an element that 'just received focus,' clustered around Chrome 127 in July and August 2024 across libraries like MUI, Ant Design, and Flowbite; the close-time 'retained focus' variant arrived later, appearing in Chrome 131 beta and nightly builds by November 2024, confirmed in Bootstrap and Angular issue trackers. Teams tracking browser behavior changes that affect shipped UI code can follow updates like this via daily.dev.
253.1K Impressions3 Comments