Blocked aria-hidden: The Warning is Proper, and Each Repair You have Discovered is Unsuitable

You closed a dialog and the console went that specific shade of indignant mustard. You highlighted the message, dropped it right into a search field, and it spat you out right here together with half the front-end web, as a result of this precise string turns up identically whether or not you’re on Angular, Bootstrap, Ionic, or phpMyAdmin.

Right here’s the half the highest outcomes bury: the warning is right. There’s an actual individual on the opposite facet of it — somebody utilizing a display screen reader whose focus is about to drop right into a gap in your web page.

And the fixes rating above me proper now all do the identical factor beneath totally different names: the blur() one-liner, the setTimeout you wrap the shut in, the trick the place you yank the aria-hidden attribute off.

Each quiets the console whereas quietly hurting the individual the browser was making an attempt to guard. In the event you’ve already shipped considered one of them, you’re in huge firm. You had been failed by your search outcomes, not careless.

I do know, as a result of I shipped one too.

One trustworthy shortcut earlier than you learn one other phrase: if you happen to can migrate to the native

aspect and name .showModal(), try this, shut this tab, and get your afternoon again, as a result of the browser runs the complete focus dance for you and this class of bug all however disappears. (You’ll nonetheless wish to deal with the case the place the aspect focus ought to return to has been faraway from the DOM, which no browser can guess for you.) All the pieces previous right here is for the remainder of us, wired right into a part library or a design system we will’t tear out this quarter.

The repair, if you happen to’re in a rush

The entire thing suits in a single sentence, and if it’s the one sentence you learn you’ll nonetheless be forward of most of what ranks above me: focus has to depart a area earlier than that area turns into hidden or inert. That’s it. All the pieces else right here is footnotes, edge circumstances, and the story of how I realized it the costly manner.

In observe it’s an order of operations. Most modal code already has the correct items, simply within the incorrect sequence — the repair is only a reordering, and the 2 variations beneath present it instantly, with the one step almost everybody skips (inert-ing the closing overlay itself) referred to as out within the feedback.

// WRONG: the order most modal code ships with
operate closeModal() {
  // background hidden whereas focus is STILL inside it → ghost focus
  overlay.setAttribute('aria-hidden', 'true');
  overlay.classList.add('fade-out');
  overlay.addEventListener('transitionend', () => overlay.take away());
  // focus restored after the disguise already dedicated; too late
  triggerButton.focus();
}

// RIGHT: hand the web page again, then focus leaves, then the area goes inert
operate closeModal() {
  // un-inert FIRST: inert blocks focus, so the set off cannot obtain focus whereas the background continues to be inert
  background.removeAttribute('inert');
  // transfer focus OUT earlier than something will get hidden
  triggerButton.focus();
  // inert, not aria-hidden, on the CLOSING shell
  overlay.setAttribute('inert', '');
  overlay.type.pointerEvents="none";
  overlay.classList.add('fade-out');
  overlay.addEventListener('transitionend', () => overlay.take away());
}

The incorrect model isn’t incorrect as a result of somebody was careless. It reads top-to-bottom precisely the way in which you’d narrate closing a modal out loud.

However the browser applies that disguise the second the assertion runs, earlier than the main focus transfer on the following line even occurs. It’s all one synchronous job. The harm is within the ordering and the invalid state that exists between these two statements, not a literal hole in time.

Get the order proper and the result’s boring — which is precisely the purpose. The person hits Esc, hears focus land again on the button they opened the factor with, and carries on.

Get it incorrect and so they land on , hear silence or simply the web page title, and should Tab from the highest of an extended web page all the way in which again to wherever they’d been. That second expertise is what the warning exists to forestall, and it’s the one blur() arms the person each time.


Let’s discuss concerning the traps you’ve in all probability already acquired open in different tabs: the blur() one-liner, the setTimeout shim, stripping aria-hidden, and modal={false} on Radix or shadcn. I’ll take every aside correctly in a bit, as a result of each one is a reasonable-looking mistake, not a dumb one.
That warning isn’t Chrome nagging you a few style-guide nicety. It’s the browser telling in your structure.
Chrome isn’t warning you. It’s overruling you.
You learn the phrase “warning” and filed it the place you file the remainder of the console: yellow, non-blocking, another person’s drawback, take care of it after the discharge. I did the identical factor.
That phrase is doing loads of harm, as a result of it tells you that is advisory — and it isn’t. By the point you see the message, the browser has checked out your markup, determined you had been incorrect, and shipped a special accessibility tree than the one you wrote.
Open the modal that triggers it and take a look at the Parts panel. Your aria-hidden="true" is true there on the background wrapper, untouched. Nothing within the DOM inspector is a lie.
Now swap to the Accessibility panel and take a look at the tree Chrome truly handed the working system’s screen-reader APIs. The subtree you informed it to cover continues to be there, nonetheless uncovered, nonetheless absolutely readable.
Chrome DevTools with the modal open: the #web page wrapper carries aria-hidden="true" (see the console warning naming the targeted button), but its whole subtree — together with the focusable hyperlinks — continues to be uncovered within the accessibility tree, as a result of a targeted aspect stays inside it.
Blink learn your attribute, noticed the targeted node residing inside that subtree, and walked again up the targeted node’s ancestor chain, ignoring your aria-hidden the entire manner. The second focus leaves, the pruning snaps again and the area hides such as you requested.
So the state you assume you shipped — the one the place that area is invisible to assistive tech — shouldn’t be the state any display screen reader receives. It exists solely in your Parts panel and your head.
That hole between the 2 panels is the entire bug, and it comes from a paradox baked into aria-hidden.
The attribute pulls content material out of the accessibility tree. It doesn’t pull that content material out of keyboard focus order. Two totally different techniques, nothing preserving them in sync.
So a component may be absolutely focusable and utterly imperceptible directly. The moment Tab lands on it, you’ve created what I’ve come to name ghost focus: the display screen reader fires a spotlight occasion for a node it’s been informed doesn’t exist, appears it up, finds nothing it’s allowed to explain, and says nothing.
Sit with what that’s like from the opposite facet of the display screen. Somebody pressed Tab. Focus moved, a management lit up, and their display screen reader went silent. Not “button, dialog.” Not the sector label. Silence.
They pressed a key, the machine acknowledged nothing, and now they don’t know if the app broke, if their assistive tech crashed, or in the event that they did one thing incorrect. They’re standing in the course of a room the map insists isn’t there, and the one manner out is to maintain tabbing blind and hope one thing ultimately speaks.
That’s what Chrome prevents when it overrules you. Left alone, aria-hidden over a targeted management doesn’t disguise something kindly; it hides the labels and retains the main focus, which is the worst of each.
Chromium has been quietly patching this for a lot longer than the warning’s been round. So far as I can reconstruct, the tree acquired loud in two installments, and I’m piecing the timing collectively from when bug experiences clustered slightly than from a changelog I can level at cleanly.
The open-time variant — the one which scolds you about a component that “simply acquired focus” — exhibits up throughout trackers round Chrome 127 in summer season 2024, clustering in July and August throughout MUI #43106, Ant Design #50170, and Flowbite #943.
The close-time variant, the “retained focus” wording, arrives months later round Chrome 131 in late 2024. The one that filed Bootstrap #41005 on November 5 caught it stay, noting it confirmed within the 131 Beta and Nightly builds however not secure but, and Angular #30187 in December matches. Two waves, one habits beneath.
That habits is previous. Chromium was already exposing focusable aria-hidden nodes again in early 2020. We all know this as a result of ARIA WG challenge #1185 data Chrome accessibility engineer Aaron Leventhal proposing precisely that, so customers may “at the very least hear the place they’re tabbing to, as a substitute of full silence.”
The sample he was defending towards goes again additional, to groups slapping aria-hidden on  or a large wrapper when a modal opened. By way of portal and markup errors, this typically hid the modal too, locking a display screen reader out of the entire web page. You may watch folks argue about that failure way back to Bootstrap #29769 in 2019.

The trustworthy framing: your teardown code was damaged years earlier than any of this reached your console. The restore was taking place silently the entire time, which is precisely why no one fastened it.
Firefox and Safari don’t floor a comparable console warning for this, so far as I’ve been capable of check; no matter every engine does about targeted content material inside a hidden subtree, it does with out telling you. Chrome determined to make you are feeling it, and I believe that decision was proper, no matter you make of the tone. A silent repair lets damaged code ship endlessly, as a result of the browser papering over your mistake is indistinguishable, out of your seat, out of your code being right. Loud is uncomfortable and loud is trustworthy.
If Chrome is repairing your tree, the query stops being “how do I make the message go away?” and turns into “at what precise prompt does my code produce a targeted node inside a hidden area?” It turns on the market are 4 distinct instants, every with its personal form.
The 4 methods you get right here
Each considered one of these ends on the identical place: focus sitting inside a area that simply went hidden. However they arrive from 4 totally different instructions, and if you happen to don’t know which one you’re taking a look at you’ll apply the incorrect repair and both not silence the warning or silence it by breaking one thing worse. Right here’s the map I want I’d had, sorted roughly by what number of of you’re residing every one.
Earlier than the deep dives, right here’s the short triage so yow will discover yours. If the warning fires once you shut a modal, throughout the fade, you’ve acquired the close-time race. If it fires the moment a modal opens, it’s the open-time inversion. If it entails a , due to course you do, it’s a kind. The person opens the  closes. And now two parts that every imagine they’re the one true modal layer are combating over who will get to cover the remainder of the web page, as a result of each ship the identical hide-others logic and neither is aware of the opposite exists.
That is the place the warning stops being noise. On shadcn #5953 you possibly can learn the entire saga of a popover inside a 
, every making use of its personal background-hiding. Builders discovered themselves bouncing between modal={true} (console spam) and the choice (an unclickable calendar) with no good possibility within the center. Annoying, however survivable.
Below React 19, it graduates from annoying to deadly. Radix #3701, filed October 2025, has the ugly title that claims all of it: Choose inside Dialog causes an aria-hidden focus freeze.
The React 19 unmount timing modified simply sufficient that when the inside Choose tears down, focus drops to  for a second. The guardian 
 reads that as a click on exterior itself, re-hides itself with the person’s focus nonetheless inside, and keyboard navigation dies. Not a warning. A web page you possibly can’t Tab by anymore.
And it’s nonetheless claiming folks. shadcn-ui #10074, from March 2026, pins the mechanism exactly: Radix’s inside hideOthers, from the aria-hidden package deal, walks each body-level sibling of the Choose’s portal and marks them hidden earlier than focus has moved off the set off.
The identical structure that merely prints a warning within the close-time race produces an unusable web page right here, which is why I refuse to deal with the console line as beauty. The repair for this class isn’t ordering, it’s telling the 2 primitives to cease each being modal, and that one wants its personal cautious walkthrough later.
The person walked out (focus leaves the web page)
Nothing in your web page modified. The person left. That they had a menu open and hit Alt+Tab, or switched browser tabs, and the main focus bookkeeping stranded an aria-hidden state on teardown with no stay focus to reconcile towards.
Materials Internet #5760 solely fires when the menu is open and focus goes to a different tab or window, a genuinely arduous case to see coming (and sure, that’s Google’s personal part library tripping on the rule Google’s browser enforces). Ionic #30240 is the routing cousin, firing on navigation between tabbed pages with no modal in sight.
This class is right here to show a degree slightly than be solved: if the maintainers of the browser can’t preserve their very own widgets clear, the issue is architectural, not a talent challenge in your crew.
Have a look at the 4 side-by-side and the shared form is unimaginable to overlook. Shut-time, open-time, turf conflict, or a person tabbing away, in each case a area grew to become hidden whereas focus was nonetheless doing enterprise inside it. 4 costumes, one bug. Which raises the one query that issues subsequent: what did the Web inform everybody to do about it?
Each repair that labored made it worse
Sort the warning right into a search field and the identical reply floats to the highest of almost each outcome. One line, drop it in your modal’s shut handler, warning gone. It really works within the sense that issues least: the console quiets and CI goes inexperienced. Right here’s what it truly does.
// the web's favourite one-liner
aspect.addEventListener('disguise.bs.modal', () => {
  // "fixes" the warning
  doc.activeElement.blur();
});
Focus doesn’t go someplace smart once you name blur() with nothing after it. It goes nowhere. The browser has to place focus someplace, so it falls again to , the DOM equal of setting a passenger down in the course of the freeway and driving off. The warning clears as a result of there’s now not a targeted aspect inside your hidden subtree, no meaningfully targeted aspect in any respect.

For a mouse person, this repair is invisible. For a keyboard or display screen reader, the reader usually goes quiet or reads one thing ineffective just like the web page title (the precise announcement varies by display screen reader and browser), and the very subsequent Tab press restarts from the highest of the complete web page. That’s an easy WCAG 2.4.3 failure, dressed up as a repair, since focus is meant to return someplace logical — canonically the management that opened the factor.
To be exact concerning the villain: it isn’t the blur() name itself, it’s blurring to nowhere. blur() instantly adopted by a deliberate set off.focus() is only a clumsy spelling of the right transfer. It’s leaving focus stranded on  that does the harm.

I understand how interesting that one-liner is, as a result of I shipped it.
Late 2024, a launch crunch, the warning out of the blue flooding our console throughout half the modals within the app after a Chrome replace we hadn’t been watching. It was loud, it was all over the place, it blocked nothing, and it made the console unreadable throughout per week once we wanted the console.
I discovered the Stack Overflow reply in about ninety seconds. One line, into a world disguise handler so it lined each modal directly.
The purple went away. Assessments handed. I keep in mind the particular small satisfaction of a one-line repair that clears a complete class of noise, and I closed the ticket and moved on and felt, actually, slightly intelligent about it.
Months later I sat in on a usability session, a kind of the place you’re principally there to take notes and keep out of the way in which. A display screen reader person was working by considered one of our flows and closed a modal — a traditional one, nothing particular, one of many ones my one-liner lined.
The reader went quiet. Then they pressed Tab to get again to what they’d been doing, and I watched them journey focus down from the highest of the web page, by the header, by the nav, cease after cease, narrating every one, working again to the spot the modal had despatched them away from.
It took some time. No person within the room however me knew why it was taking place.
The warning I’d silenced had been the one voice within the constructing talking for that person, and I’d put my hand over its mouth to make my console tidy. That’s the entire thing. That’s why this text exists.
I’m not going to sit down in that feeling, as a result of sitting in it fixes nobody’s modal. The helpful half isn’t the guilt, it’s the mechanism: I’d handled a warning a few person as a warning about my logs, and each repair I reached for optimized the logs. When you see that, the remainder of the folks treatments kind themselves by the identical inform.
The timing hacks are second hottest, and subtler, as a result of they generally work. The transfer is to wrap open or shut in a setTimeout or requestAnimationFrame so focus restoration occurs a tick later, after the disguise has settled.
// wager on the render ending first
requestAnimationFrame(() => triggerButton.focus());
Neighborhood recommendation floating across the shadcn threads is remarkably trustworthy about what you’re shopping for: roughly, add a delay, you’ll nonetheless see the warning typically, however principally it really works (shadcn #5953 has this precise resigned power).
That “principally” is the issue. A timer bets the paint finishes earlier than the main focus name runs, and on a quick machine with a heat cache you win more often than not. Below CPU load, on an inexpensive Android, or beneath React’s concurrent rendering the place the scheduler slices your work aside, you lose.
Whenever you lose, the damaged hidden-with-focus state ships anyway, now intermittently, which is worse, as a result of it gained’t reproduce in your machine. You’ve added latency to each shut for each person to sometimes-not-fix an issue for the few. These flickering half-committed states are the sort of factor WCAG 4.1.2 exists to rule out.
Stripping the attribute is the following tier down, and it appears probably the most like addressing the foundation trigger whereas doing the alternative. Some folks delete aria-hidden from their markup; the extra decided wire up a MutationObserver to yank it off each time the library units it.
The warning genuinely goes away, as a result of now nothing is hidden. That’s the difficulty: whereas your modal is open, the complete background web page is handed again to the display screen reader. The person can Tab out of the energetic modal and into background controls, regardless that the modal is meant to be the one a part of the web page they’ll function. That breaks the fundamental modal contract and creates an illogical focus order — a WCAG 2.4.3 (Focus Order) failure.
Then there’s modal={false}, the Radix and shadcn escape hatch. Setting this turns the part right into a reliable non-modal dialog — an actual, legitimate sample in its personal proper. The issue is utilizing it particularly to silence the warning whereas preserving the visible backdrop of a blocking modal. You give customers one thing that appears modal however doesn’t behave modally, clearing the warning by eradicating the main focus entice fully.
Radix #3811 paperwork the place that lands: in Safari, focus tabs its manner proper out of the non-modal dialog, and Radix, seeing focus go away, reads it as an outdoor interplay and closes the dialog on the person, mid-form. You’ve silenced a console warning by delivery a dialog that dismisses itself whereas somebody’s filling it in.
Two extra deserve precisely one sentence every. The non permanent tabindex="-1" on  adopted by a spotlight dump is blur() with further ceremony and the similar outcome. Filtering the message out of your console output is the software program equal of taping over the check-engine mild and having fun with the quieter dashboard.

None of that is the fault of the individuals who posted these solutions, and proper steering does exist: Scott O’Hara has written fastidiously about inert for years, and MDN’s 
 documentation lays out the correct mannequin.
It simply doesn’t rank once you’re panicking at 4:00 p.m. with a purple console and a deploy window. The great materials is quiet and the unhealthy materials is optimized, and that asymmetry is the precise villain.
So right here’s the thesis the entire piece hangs on: a clear console was by no means the objective. You may drive this warning to zero and, at each step down that highway, make your product measurably worse for the precise folks the warning was put there to guard. The warning is a proxy. The person is the goal.
Which suggests the actual repair has to fulfill each directly, the browser and the individual, and that comes all the way down to doing 4 issues in a selected order.
The teardown contract
The rule the entire repair reduces to is brief sufficient to maintain in your head. On shut, focus leaves the closing area earlier than that area is hidden, and it should land someplace actual, by no means on an inert node and by no means on .

That second half has a consequence folks journey on. inert blocks focus. So in case your set off sits contained in the background you inert-ed on open, you need to raise that inert earlier than you possibly can focus the set off in any respect, or .focus() is a silent no-op and focus stays stranded contained in the dialog.
So the 4 ordered steps are:

take away inert from the background;
restore focus to the saved set off synchronously, earlier than any hide-state touches the DOM;
apply inert and pointer-events: none to the closing overlay shell itself, so its fade-out runs on a component that’s visually current however lifeless to focus and the accessibility tree;
unmount when the transition ends.

(In case your set off lives exterior the inerted area, the primary two steps commute and also you’ll see the focus-first order in some codebases. Protecting background-first is the protected default as a result of it really works both manner.)
There’s a corollary at open time that most individuals already do by intuition: seize the return goal, doc.activeElement, earlier than you progress focus into the dialog. As soon as focus is inside, the factor you needed to return to is gone.
The step I wish to single out is the third, as a result of it’s the one I acquired incorrect for months after I believed I’d realized my lesson. The widespread recommendation, when you get previous blur(), is “simply restore focus first.” That’s crucial and never adequate.
Restore focus to the set off and also you’ve cleared the warning, however the overlay continues to be fading out for one more 200 milliseconds, nonetheless within the DOM, nonetheless focusable and nonetheless within the accessibility tree whereas it fades. A display screen reader can catch it on the way in which down; VoiceOver’s cursor will contact that ghost content material if you happen to let it.
Inert-ing the dying shell is what truly closes the opening, and it’s the trustworthy reply to the query everybody asks first, which is learn how to animate the factor out with out the warning coming again. You don’t suppress the warning throughout the fade. You make the fading aspect inert so there’s nothing to warn about.
Why doesn’t this occur by default? As a result of the frameworks commit the disguise earlier than they restore the main focus, for a structural motive slightly than a careless one.
In React, the state change that provides your hidden class or your aria-hidden attribute applies throughout render. The main target-restoration code you tucked right into a useEffect cleanup runs after paint, a body later, which is the place an actual hole in time does open up. So the browser will get handed hidden-with-focus-inside, fires the warning and does its tree restore, and solely then does your .focus() name run.
You wrote the 2 operations in the correct order in your supply; React scheduled them within the incorrect order at runtime. The repair is to maneuver the main focus name out of the after-paint impact and run it earlier than the disguise commits, because the pattern beneath does. Vue has the identical illness by nextTick() and Transition-hook ordering, Angular CDK by its FocusTrap timing; the trigger is similar, solely the API names change.
The vanilla model
Strip away the framework and the contract is straightforward to see as a result of there’s no scheduler between you and the DOM. That is the reference I hand people who find themselves on jQuery, Internet Parts, or nothing in any respect.
class ModalController {
  // the place focus goes residence to
  #set off = null;
  // the sibling subtree we inert whereas open
  #background = null;

  open(dialog) {
    // corollary: seize BEFORE we transfer focus in, or it is misplaced
    this.#set off = doc.activeElement;
    this.#background.setAttribute('inert', '');
    dialog.hidden = false;
    dialog.querySelector('[autofocus], button, [href], enter')?.focus();
  }

  shut(dialog) {
    // STEP 1: hand the web page again FIRST. inert blocks focus, so if the set off lives contained in the background, focusing it whereas the background continues to be inert is a silent no-op. Un-inert, then focus.
    this.#background.removeAttribute('inert');

    // STEP 2: focus goes residence synchronously, earlier than any hide-state lands.
    // That is the road whose ORDER the warning is admittedly about.
    this.#set off?.focus();

    // STEP 3: the dying shell is inert, not aria-hidden. It could fade out in peace: unreachable by Tab, invisible to AT, no clicks.
    dialog.setAttribute('inert', '');
    dialog.type.pointerEvents="none";
    // CSS drives the fade
    dialog.classList.add('is-closing');

    // STEP 4:  unmount when the animation ends. 
    // Three traps:
    // (1) transitionend bubbles from youngster components (guard on e.goal)
    // (2) it by no means fires in any respect when there's nothing to attend for (period + delay each 0) or the shut is interrupted (transitioncancel)
    // (3) you need to NOT use { as soon as: true } right here  —  a bubbled youngster occasion would eat the one-shot listener earlier than the dialog's personal transition ever finishes.
    // Take away listeners by hand, and solely after accepting the dialog's personal occasion.
    const performed = () => {
      dialog.hidden = true;
      dialog.classList.take away('is-closing');
      dialog.removeAttribute('inert');
      dialog.type.pointerEvents="";
    };
    const end = (e) => {
      // a baby's transition bubbled up; ignore it
      if (e && e.goal !== dialog) return;
      dialog.removeEventListener('transitionend', end);
      dialog.removeEventListener('transitioncancel', end);
      performed();
    };
    const type = getComputedStyle(dialog);
    const dur = parseFloat(type.transitionDuration) || 0;
    const delay = parseFloat(type.transitionDelay) || 0;
    if (dur + delay <= 0) {
      // no transition to attend for (e.g. a reduced-motion CSS rule zeroed it)
      performed();
    } else {
      dialog.addEventListener('transitionend', end);
      dialog.addEventListener('transitioncancel', end);
    }
  }
}
Nothing intelligent is occurring right here, and that’s the purpose. The set off is saved on open, the web page is handed again earlier than focus strikes, focus is distributed residence earlier than a single hide-state lands, and the overlay is inert for the entire period of its personal exit animation.
One caveat earlier than you paste it into manufacturing: the one #set off slot holds precisely one return goal, which is ok for one modal at a time however incorrect the second modals stack or a fast open-close-open overlaps. For that you really want a stack of triggers slightly than a discipline, which is the primary of the sting circumstances beneath.
The transitionend bookkeeping is the least nice a part of this, and if you happen to’d slightly the JavaScript personal the animation you possibly can drive the fade with the Internet Animations API as a substitute, the place aspect.animate(...).completed arms you a promise and the listener cleanup disappears.
I’ve stored the CSS-transition model right here as a result of it’s how the overwhelming majority of the affected code within the wild is definitely written, and matching that’s the level. The guard code is the trustworthy value of the CSS strategy, not incidental noise.
The React model
The identical contract, combating the scheduler. The invariant is unchanged: focus has to land on the set off earlier than the state change that inerts or hides the area commits. Three issues break that by default in React.
First, folks seize the return goal too late. In the event you seize doc.activeElement in an impact that runs after isOpen flips, an autofocus impact might have already got moved focus into the dialog, so that you retailer the incorrect aspect. Seize it within the handler that opens the dialog, earlier than you flip the state.
Second, folks restore focus in a cleanup impact that runs after paint, so the browser sees hidden-with-focus-inside first and warns.
Third, and that is the delicate one: if the background’s inert is itself pushed by state, setIsOpen(false) adopted on the following line by set off.focus() gained’t work. React batches the state replace, so the DOM nonetheless has the set off sitting inside an inert container when .focus() runs, and the main focus silently fails precisely the way in which the vanilla no-op did.
The cleanest reply to that third one is to not route background inertness by render state in any respect. Whether or not the web page behind a modal is inert is an crucial facet impact, not view knowledge: toggle the attribute instantly, or use native 
 and let the highest layer make it implicit, and the batching drawback by no means exists. In the event you’re dedicated to preserving it in state, that is the case flushSync was constructed for.
operate useModalTeardown() {
  const triggerRef = useRef(null);
  // the wrapper you inert whereas the modal is open
  const backgroundRef = useRef(null);

  // seize within the OPEN handler, earlier than state flips  —  not in a post-open impact, the place an autofocus impact might have already got stolen focus
  const open = useCallback((setOpen) => {
    triggerRef.present = doc.activeElement;
    if (backgroundRef.present) backgroundRef.present.inert = true;
    setOpen(true);
  }, []);

  // Restore focus BEFORE the state replace that hides/inerts the area.
  // The background's inert is toggled imperatively right here (not by way of state), so the set off is reachable the moment we un-inert and there is no batching between the un-inert and the main focus name.
  const shut = useCallback((setExiting) => {
    // hand the web page again
    if (backgroundRef.present) backgroundRef.present.inert = false;
    // transfer focus residence first...
    triggerRef.present?.focus();
    // ...then commit the exiting/hidden state
    setExiting(true);
  }, []);

  return { triggerRef, backgroundRef, open, shut };
}

// The exiting shell renders inert whereas a CSS class runs the fade.
// Guard the unmount the identical manner the vanilla model does: transitionend bubbles (verify e.goal) and will not fireplace with no transition (period 0).
operate ModalShell({ exiting, onDone, kids }) {
  const onEnd = (e) => { if (e.goal === e.currentTarget) onDone(); };
  return (
    
      {kids}
    
  );
}
If the background’s inertness genuinely must be React state, ordering alone can’t prevent, as a result of the un-inert and the main focus name are separated by React’s batching. That is the case flushSync exists for: drive the state replace that removes the background’s inert to decide to the DOM earlier than you name .focus().
// commit the un-inert to the DOM NOW
flushSync(() => setIsOpen(false));
// set off is reachable, so this lands
triggerRef.present?.focus();
// then begin the fade
setExiting(true);
Be aware what’s truly wrapped: the state replace whose DOM impact you depend upon, not the .focus() name, which is already synchronous. That distinction is the entire motive a naked flushSync(() => set off.focus()) does nothing. flushSync has an actual batching value, it throws if you happen to name it throughout render, and most teardown code avoids needing it fully by toggling background inertness imperatively or transferring to native 
. Attain for the crucial toggle first; attain for flushSync solely when the inertness should keep in state.
In the event you solely change one factor in your current React modal, it’s this: seize the set off within the open handler, and run the main focus restoration earlier than the disguise state commits slightly than in an after-paint impact. That reorder is the entire distinction between the warning and no warning, and between your display screen reader person touchdown on the set off and touchdown on .

Price saying plainly: inert is the correct instrument and aria-hidden was at all times the incorrect one for this job. aria-hidden removes a subtree from the accessibility tree however leaves it absolutely focusable, the complete ghost-focus gap. inert removes it from the accessibility tree, from sequential focus navigation, and from pointer occasions (the HTML spec is express that inert components can’t be targeted, and MDN’s inert reference paperwork the identical three results), which is why Chrome’s personal message factors you at it. One entice: by no means put inert on an ancestor of a top-layer aspect otherwise you’ll freeze the top-layer aspect itself, dialog included. Apply it to the sibling subtrees you truly need lifeless, to not a wrapper that incorporates your stay dialog.
Evaluating main implementations
How the main implementations sequence this varies greater than you’d hope.




Library
When focus is restored
Hiding mechanism
Verdict




Native 
Browser-internal, on shut
Prime layer, implicit inertness
Greatest default*


React Aria
Synchronous, layout-effect timing
FocusScope + inert path
Strongest {custom}


Radix
Pre-unmount by way of onCloseAutoFocus
hide-others / aria-hidden
Acceptable, React 19 caveat


Bootstrap 5.3
On hidden.bs.modal, after the fade
aria-hidden on wrapper
The failing sample


Floating UI
Managed by FloatingFocusManager
Moved to inert suppression
Good path




Native 
 earns “finest default,” not “flawless”: it eliminates the ghost-focus class outright, however focus return on shut solely works if the previously-focused aspect continues to be there and focusable, and autofocus placement contained in the dialog has had cross-browser wrinkles price testing. You may animate its exit now with @starting-style and transition-behavior: allow-discrete.
As detailed within the close-time-race part above, Bootstrap 5.x is the canonical failing sample right here, and model 6 abandons it for native showModal().
Radix is defensible: onCloseAutoFocus restores earlier than unmount, which is ok, with the trustworthy asterisk that React 19’s unmount timing modifications launched the freeze talked about earlier. React Aria’s FocusScope is the one I’d research if you happen to’re constructing your personal, as a result of it restores synchronously by way of layout-effect timing and sidesteps the entire race by building.
For many of us sustaining current design techniques with deep portal architectures, although, migrating to native 
 isn’t an possibility this quarter. That’s precisely who the four-step teardown contract is for.
4 edge circumstances the contract has to outlive, and every one breaks the UI in its personal manner if you happen to skip it.
The set off now not exists. The kebab menu opened a dialog, and the dialog deleted the row the kebab lived in. Restoring focus to a indifferent aspect silently drops you to , so retailer a fallback, the checklist container or the closest heading with tabindex="-1", and ship focus there as a substitute.

Modals stack. A modal opens one other modal. Every layer shops the aspect that opened it, so restoration chains and the closes unwind like a stack, innermost first. That is the case the single-slot set off storage from earlier can’t deal with.
The person left the web page. An Alt+Tab or a tab swap with the overlay nonetheless open. Don’t run restoration towards a stale activeElement on window blur; wait and reconcile focus when the window comes again.
There’s no transition to attend for. This one isn’t glamorous nevertheless it’ll hold your UI chilly. In the event you gate the unmount on transitionend, that occasion by no means fires when no transition runs, which is precisely what occurs beneath prefers-reduced-motion: cut back or when a person closes quick sufficient to interrupt the fade. Run the teardown instantly when the computed transition period is zero, or the closing shell sits within the DOM, inert, endlessly.
That’s the contract. Subsequent I’ll put a display screen reader on it and present you the distinction between the damaged shut and the right one, since you shouldn’t take my phrase for any of this.
Don’t take my phrase for it
You’ve simply learn just a few thousand phrases arguing that fixes with a whole bunch of upvotes are actively dangerous, written by somebody who admits he shipped considered one of them. That’s precisely the sort of declare you shouldn’t settle for on belief. So I constructed the argument into one thing you possibly can run, and I’d slightly you catch me being incorrect than imagine me being proper.
The demo:
CodePen Embed Fallback
It’s vanilla JavaScript, no framework, so what you’re watching is the uncooked ordering with no scheduler in the way in which. 4 modals sit facet by facet, every closing a special manner: variant 1 is the naive teardown that units aria-hidden on the modal whereas the shut button nonetheless holds focus and solely restores focus within the transitionend handler; variant 2 is the blur() “repair”; variant 3 hides synchronously however defers focus restoration right into a setTimeout; and variant 4 runs the contract, un-inert, focus residence, inert the closing shell, unmount. Each logs doc.activeElement at each lifecycle tick, open, close-start, transition-end, straight to the console, subsequent to no matter Chrome prints by itself.
Open the console first, then work high to backside. Open variant 1, shut it with the keyboard, not the mouse (Escape, or Tab to the shut button then Enter), and watch two issues: whether or not the “retained focus” warning fires throughout the fade, and the place the activeElement log says focus is sitting whereas it does.
The prediction right here is delicate, and that’s the purpose of placing it first: Chrome’s tree restore retains the targeted content material uncovered, so a display screen reader person is quietly saved by the browser regardless that your markup is incorrect. The warning fires. The person is generally superb.
That hole between “your code is damaged” and “the person seen” is why this shipped all over the place for years.
Variant 2 is the place you must decelerate. Shut it and skim the activeElement log on the tick proper after shut: as anticipated, it reads physique.
In the event you do that with a display screen reader working (like NVDA or VoiceOver), the result is precisely what we mentioned earlier: silence, or a ineffective web page title announcement.
Whenever you press Tab, focus restarts from the very first focusable aspect on the web page. On the demo’s deliberately-long scaffold, you’ll be compelled to Tab by the complete header and nav simply to get again.
The console, in the meantime, is clear. No warning. That’s the entire entice on one display screen: inexperienced console, person stranded on the freeway.
Variant 3 is the instructive one. On this plain-JS demo it warns each time you shut it: the disguise commits synchronously whereas focus continues to be inside, and the setTimeout solely strikes focus in a later job. The invalid state within the window between these two might by no means be painted as a visual body, however Chrome detects it and warns regardless. That’s the trustworthy lesson — a delay doesn’t take away the warning, it simply relocates it — and, as lined earlier, beneath actual CPU load or concurrent rendering it stops relocating cleanly and begins failing intermittently.
Variant 4 needs to be boring, which is the target. Shut it and the prediction is a warning-free console and an activeElement log that reads the set off button instantly, on the close-start tick, not three ticks later. Run it beneath a display screen reader and the expected habits is a plain handoff: focus lands on the management you opened the modal with, that management is introduced, and the following Tab continues from there slightly than from the highest of the doc. No person will get stranded. If a modal shut could possibly be referred to as uneventful, that’s the one.
Right here’s the half that ought to trouble you if you happen to lean on CI to catch this: run an axe or Lighthouse scan towards all 4 variants and a number of other of the damaged ones go.
They go as a result of these scanners examine the state of the markup, and within the resting state the markup is ok, the aria-hidden is gone, the dialog closed, nothing to {photograph}.
The failure doesn’t stay in any single body. It lives within the 200 milliseconds between two frames, within the order operations occurred, and a scanner that pictures the web page won’t ever catch a bug that solely exists within the movie between the photographs. That’s why this wants a human with a keyboard and a display screen reader, and why it slipped previous each automated gate we had.
In the event you run this on an AT or browser model I haven’t tried and get totally different outcomes, please file it on the demo repo; I’d just like the article to be much less incorrect over time, and disagreement from an actual NVDA construct beats my predictions.
So whose bug is it, actually?
Begin with the maintainers, as a result of their case is stronger than the browser partisans give them credit score for. Chrome dropped a warning that reads like a scolding, in two waves no one introduced, onto teardown code that had labored superb for a decade. And it wasn’t sloppy code.
Fade the overlay out, restore focus when the animation ends: that was the idiomatic sample, the one each tutorial taught, the one baked into Bootstrap’s personal hidden.bs.modal timing. A maintainer who shipped that in 2019 was following the documented form of the day, after which one Tuesday their tracker fills with experiences for a warning their customers are satisfied is release-blocking, on habits that didn’t change on their finish.
A few of these points understandably sat unresolved or ping-ponged between “that’s a Chrome bug” and “that’s your integration,” as a result of from the place the maintainer sits, each are half true and neither is their fault. In the event you keep a part library, that complete expertise was genuinely unfair, and I gained’t faux in any other case.
The browser facet solutions cleanly, although. Hiding focusable content material from assistive tech was by no means allowed by what WAI-ARIA implied, and the APG modal-dialog sample spells out the focus-management contract a dialog is meant to honor. Chromium had been silently repairing this precise defect for years, and the protecting stance is on the file all the way in which again in ARIA WG challenge #1185 from 2020.
The uncomfortable proof is behavioral: libraries began migrating to inert solely after the console acquired loud. The silent restore sat there for years and moved no one. The warning shipped and inside months Shoelace, Ant Design, and Floating UI had been transforming their teardown.
Loudness was the one factor that ever made the ecosystem act, which is a clumsy factor to be proper about.
After which the individuals who acquired it worst, who did nothing incorrect architecturally: app builders beneath a contractual or inside zero-console-warnings rule. They inherited the warning from a library they don’t management, reached for the top-ranked repair to fulfill the rule, shipped blur(), after which acquired flagged by an accessibility auditor for each the unique defect and the WCAG failure the hack launched.
They paid twice for an issue that originated two layers above them. You’ll discover the folks knowledge that it’s innocent throughout group threads, the identical shadcn dialogue from earlier amongst them, the place accepting the warning whereas chasing a useful repair slides quietly into treating it as beauty sufficient to ship.
All the pieces above is the rebuttal, and the folks repeating it aren’t fools; they’re downstream of the identical unhealthy search outcomes I used to be.
Right here’s the place I land, plainly. The browser is true on the deserves: you can not disguise a targeted management from a display screen reader and name it an accessible modal, full cease. The rollout communication was poor, and the maintainers’ frustration about that’s reliable. However the sturdy repair lives within the part layer, not the browser and never 100 app-level patches, as a result of the part is the one place that owns each the main focus and the hiding and may get them organized appropriately. That’s why I spent the longest part on an ordering contract slightly than anyone library’s changelog. Libraries will patch and un-patch; the invariant is what you retain.
Which can also be why I believe this outlasts its personal specifics. The precise console string will get reworded. Bootstrap already resolved its case the sturdy manner, closing the inert patch and transferring to native 
 in model 6, and different libraries will preserve patching and re-patching their very own rows. Firefox and Safari restore silently right now, with no comparable console warning, and will go loud tomorrow.
However the standardization path is now not one thing I’m guessing at: ARIA WG challenge #2422 requested whether or not the working group ought to standardize this type of heuristic ignoring of ARIA, was labored by 2025, and closed round March 2026, with the group’s personal minutes alongside the way in which acknowledging current heuristics like disregarding aria-hidden on . The path is actual and settling.

The ordering drawback between focus and hiding, although, is architectural, and each overlay system in each framework not but written will meet it, which is why folks had been nonetheless submitting contemporary situations like shadcn-ui #10074 in March 2026.
The one future I’d welcome is native 
 and the highest layer consuming the custom-modal class complete, and if that occurs and this piece turns into a historic curiosity about an issue no one has anymore, I’ll be glad to have written one thing with an expiration date.
You bought right here with a red-yellow console and a string pasted right into a search field, aggravated, mid-deploy, wanting the noise gone. The warning turned out to be the one factor in your complete toolchain talking for somebody who wasn’t within the room once you shipped, the individual I watched Tab again by a complete web page header in a silence I’d prompted.
So don’t attain for the mute. The warning isn’t noise on high of your structure; it is your structure, saying out loud what it does to somebody the second you cease watching.

Library	When focus is restored	Hiding mechanism	Verdict
Native	Browser-internal, on shut	Prime layer, implicit inertness	Greatest default*
React Aria	Synchronous, layout-effect timing	`FocusScope` + inert path	Strongest {custom}
Radix	Pre-unmount by way of `onCloseAutoFocus`	hide-others / aria-hidden	Acceptable, React 19 caveat
Bootstrap 5.3	On `hidden.bs.modal`, after the fade	`aria-hidden` on wrapper	The failing sample
Floating UI	Managed by `FloatingFocusManager`	Moved to inert suppression	Good path



						
						
														Tags: ariahiddenblockedFixWarningwrongyouve

Blocked aria-hidden: The Warning is Proper, and Each Repair You have Discovered is Unsuitable

The person walked out (focus leaves the web page)

Each repair that labored made it worse

The teardown contract

The vanilla model

The React model

Evaluating main implementations

Don’t take my phrase for it

So whose bug is it, actually?

Admin

How To Again Up Your MacBook With out Paying For Cloud Storage

Leave a Reply Cancel reply

Recommended.

Dental Advertising and marketing Firm in Seattle

Infantilization | Seth’s Weblog

Trending.

The Full Information to EcoGPT

Customers, Progress, and International Tendencies

Authorized DUI PPC Companies in Atlanta

Telegram ban in India sparks a rush to VPNs, rival apps

12 Various Search Engines to Strive (As a substitute of Google)

AimactGrow

Categories

Recent News

Take into account the AI tear down

Cannot Log Into Your Netgear Router? Strive One Of These Fixes