Modal and Drawer Done Properly: Focus Trap, Scroll Lock, Inert

A correct modal traps focus inside itself, locks background scroll, makes the rest of the page `inert`, and returns focus to the trigger on close. Three out of four is not a partial pass — each missing one produces its own concrete failure.

`Modal` and `Drawer` do all four. That is why `Modal` costs 2.9 kB rather than a few hundred bytes: the visual part of a dialog is a positioned box, and essentially all of the code is the behaviour around it.

Without a trap, Tab eventually moves focus behind the dialog to the page underneath. The user is now interacting with content they cannot see, while a visible overlay implies it is unavailable. There is no indication anything has gone wrong — focus simply stops appearing anywhere useful.

Trapping means Tab from the last focusable element wraps to the first, and Shift+Tab from the first wraps to the last. Focus should move into the dialog when it opens — usually to the first focusable element, or the dialog itself when it opens with static content.

The naive scroll lock is `overflow: hidden` on the body. On any platform with a classic scrollbar this removes the scrollbar, the viewport gets wider, and the entire page jumps sideways as the dialog opens. It is a small effect that looks conspicuously broken.

The fix is compensating for the scrollbar width so the layout stays still. This is the kind of detail that separates a dialog someone built once from one that has been used in production — you notice it immediately when it is wrong and never when it is right.

Focus trapping handles Tab. It does not stop a screen reader user from navigating into the background content by heading or landmark, because that navigation does not use focus at all. Those users can read a page that is visually behind an overlay and has no business being available.

`inert` on the background solves it properly: the browser removes that subtree from the accessibility tree and from focus order together. Before `inert` this needed `aria-hidden` plus manual focus management, and getting the pair consistent was a common source of bugs.

When a dialog closes, focus must return to the element that opened it. Without this, focus falls back to the document body and a keyboard user restarts from the top of the page — after every single dialog interaction.

It is forgotten because it is invisible with a mouse. You click a button, a dialog opens, you close it, everything looks fine. The bug only exists for people navigating by keyboard, which is precisely why it survives code review so often.

A drawer has the same four requirements. The frequent mistake is treating a slide-in panel as a layout element rather than a dialog, which means it gets none of them — no trap, no scroll lock, no inert background, no focus return.

The test is whether the background is meant to be unavailable while it is open. If it is, it is a dialog regardless of how it animates in, and it needs the full behaviour. And as everywhere else in the library, the animation respects `prefers-reduced-motion`.