Modal, Dialog & Overlay Patterns

The plain-language idea

Modal overlays block interaction with the rest of the page and demand a decision before the user can go back to it — a delete confirmation, a required setup step. Non-modal overlays (a popover, a dropdown menu, a toast) coexist with the page: the user can ignore them, click elsewhere, and they'll dismiss without forcing a choice. The distinction isn't the backdrop or the visual style — a popover can have a subtle shadow and a modal can have none — it's whether the background stays interactive.

Once something is a true modal, two behaviors aren't optional polish, they're the actual contract:

• Focus trapping — while the modal is open, Tab and Shift+Tab should cycle only among the modal's own focusable elements. If focus can escape to something behind the overlay, a keyboard user can interact with content that's supposed to be blocked — a real, common accessibility bug, not a hypothetical edge case.
• Returning focus to the trigger — closing the modal should put keyboard focus back on whatever element opened it, not reset it to the top of the page or <body>. Otherwise a keyboard user has to re-navigate from scratch to find where they were.

See it in a real thing: native <dialog> versus a hand-rolled overlay

<dialog id="confirm">
  <p>Delete this item?</p>
  <button value="cancel">Cancel</button>
  <button value="confirm">Delete</button>
</dialog>

const trigger = document.querySelector("#delete-btn");
const dialog = document.querySelector("#confirm");

trigger.addEventListener("click", () => dialog.showModal());
// showModal() traps focus inside the dialog and makes the rest of the page inert automatically

dialog.addEventListener("close", () => trigger.focus());
// returning focus is still the author's job — no browser API does this part for you

Idle — a trigger button sits on the page. The modal is closed and focus is wherever the user left it.

BackNext

The native <dialog> element's showModal() is one of the rare cases where the platform does the hard part for free: focus trapping and marking the background inert are both handled automatically. A hand-rolled position: fixed overlay built from a plain <div> has to reimplement that manually — tracking the first and last focusable elements inside it and intercepting Tab at the boundaries. What neither approach gives you for free is returning focus to the trigger on close — that line is always the author's responsibility, native or custom.

What people usually miss

Watch out

• Non-modal overlays don't need focus trapping. A popover or dropdown is deliberately non-blocking — the background stays interactive by design, so trapping focus inside it would be wrong, not just unnecessary.
• Escaping the trap is a real, common bug, not a rare one. It usually happens silently: a modal built without explicit Tab handling lets focus wander onto a "hidden" element behind the backdrop that's still technically in the DOM and still focusable.
• Resetting focus to <body> on close is a common half-fix. It stops focus from vanishing entirely, but a keyboard user still has to tab all the way from the top of the page to get back to where they were — the fix is a specific return target, not just "somewhere valid."
• Nested modals compound both problems. Each layer needs its own trap, and closing one needs to return focus to the layer beneath it, not jump straight to the original page.

Why this matters in interviews

"Why does this modal feel broken when I use only the keyboard" is a real, specific diagnostic question — the strong answer names focus trapping and return-to-trigger by name, and can describe what a platform primitive like <dialog> handles automatically versus what a hand-rolled overlay still has to implement manually.