The Dialog Gate: why your div modal lets Tab escape, and how <dialog> fixes it

The painted door

Kai needs a confirm box before the user leaves the dojo. He builds it the way many of us learned: an overlay, a box, a very large z-index, and a line of JavaScript to show it.

<div class="overlay"></div>
<div class="modal" id="leave">
<h2>Leave the dojo?</h2>
<button id="stay">Stay</button>
<button id="go">Leave</button>
</div>

// .modal { position: fixed; z-index: 9000; display: none; }
openBtn.onclick = () => { leave.style.display = 'block'; };

KaiIt sits on top of everything. Looks like a modal to me.

To a mouse user, it is. Now try it with a keyboard:

1. Focus stays behind. Opening the box doesn't move focus into it. Focus is still on the button you clicked, underneath the overlay.
2. Tab walks out. Tab moves to the next focusable element in the document, so after Stay and Leave it lands on links and inputs in the page behind, which you can't even see.
3. Escape means nothing. A div has no idea it is supposed to close.
4. Screen readers keep reading the page. Nothing announces a dialog, and the content behind the overlay is still in the accessibility tree.
5. The z-index war. A z-index only competes inside its own stacking context, so a sticky header or a transformed parent can still end up on top of your box.

VishwaYou can patch every one of those with code: a focus trap, a keydown listener, aria-hidden on everything else, and a z-index arms race. Or you can use the gate the browser already built.

The fix: a real gate

HTML has a dialog element. Put a form inside it with method="dialog", give each button a value, and open it with showModal().

<button id="openBtn">Leave the dojo</button>
<dialog id="leave" aria-labelledby="leave-title">
<form method="dialog">
<h2 id="leave-title">Leave the dojo?</h2>
<button value="stay" autofocus>Stay</button>
<button value="leave">Leave</button>
</form>
</dialog>

openBtn.addEventListener('click', () => {
    leave.returnValue = '';
    leave.showModal();
});
leave.addEventListener('close', () => {
    if (leave.returnValue === 'leave') goHome();
});

dialog::backdrop { background: rgb(28 18 9 / 0.6); }

When a button submits a method="dialog" form, the dialog closes and its returnValue becomes that button's value. Nothing is sent to a server. Pressing Escape also closes a modal dialog, but it doesn't set returnValue, so the old value would stick around if you reuse the dialog. That is why the opener resets it to an empty string first.

KaiNo z-index, no key listener, no focus trap. Just HTML!

What showModal() does for you

One method call, six jobs. Because the page behind is inert, Tab can't reach it: focus moves through the dialog's controls and, past the last one, out to the browser's own toolbar, never onto the page underneath.

Gates that still leak

• show() or the open attribute makes a non-modal dialog. No inert page, no backdrop, and Escape doesn't close it. For a modal, always call showModal().
• Clicking the backdrop doesn't close it by default. If you want that, close it when the click lands on the dialog element itself (see below). Newer browsers also support closedby="any", but check support before relying on it.
• Don't put tabindex on the dialog. The dialog itself isn't interactive. Use autofocus on the control that should get focus first.
• Give it a name. Point aria-labelledby at the heading so screen readers announce what the dialog is about.
• Keep a visible close button. Not everyone has an Escape key, and touch users need something to tap.

// The dialog has padding: 0 and its content sits in an inner wrapper,
// so a click whose target is the dialog itself landed on the backdrop.
leave.addEventListener('click', (e) => {
    if (e.target === leave) leave.close();
});

KaiSo even a real gate leaks if I open it with show().

Inspect the gate in DevTools

1. Elements panel. Open the dialog, then select it in Chrome DevTools. An open modal dialog shows a top-layer badge, and its ::backdrop appears as a pseudo-element right inside it.

2. Accessibility pane. With the dialog selected, open the Accessibility pane. The computed role should be dialog, and the name should come from your heading via aria-labelledby.

3. Console. Check where focus is before and after.

// after showModal() document.activeElement //
<button value="stay" autofocus>
// after closing with Esc or a button
document.activeElement // <button id="openBtn">

If focus is still on the opener after the dialog opens, or Tab reaches anything behind it, the Hollow Wall is still standing.

VishwaFocus goes in, Escape works, focus comes home. That is a gate.