A modal steals the whole room.

An accessible modal dialog is not a styled overlay. It is a contract with the keyboard and the screen reader, and the WAI-ARIA Authoring Practices name six terms of it. Miss any one and the modal is broken for someone. The good news is in Section 2: the native element hands you all six.

<dialog> opened with .showModal() gives you the whole contract for free and correctly: focus moves in, Tab is trapped, Escape closes, the background goes inert, and focus returns to the trigger on close. It renders in the top layer, so it sits above the page with no z-index fight, and it exposes a ::backdrop to dim what is behind. Building this by hand means re-deriving every one of those behaviors, and that is exactly where accessibility bugs are born.

Open the demo below. Tab through it and the focus stays inside. Press Escape and it closes. Notice the dimmed ::backdrop. The Cancel and Save buttons live in a <form method="dialog">, so activating either closes the dialog and reports its returnValue without a submit or a page reload. There is a real close button too, because Escape alone is not a discoverable exit.

<!-- Open with .showModal(), never the open attribute. -->
<button onclick="dlg.showModal()">Rename event</button>

<dialog id="dlg" aria-labelledby="dlg-title">
  <!-- method="dialog" closes on submit, no reload, sets returnValue -->
  <form method="dialog">
    <h3 id="dlg-title">Rename event</h3>
    <input autofocus value="Summer Rooftop Session">
    <button value="cancel">Cancel</button>
    <button value="save">Save name</button>
  </form>
</dialog>

The role is not decoration. role="alertdialog" tells assistive tech this dialog interrupts to demand a response, so it can treat it specially, a system alert sound for instance. Use it for confirmations and destructive or irreversible actions. Use plain dialog for forms, selection, and content. The decision rule is one line.

An alertdialog carries every requirement from Section 1 plus two of its own: aria-describedby must point at the element holding the alert message, and the safest initial focus is the Cancel button, not the destructive one. Putting focus on Cancel makes the dangerous choice deliberate rather than one stray Enter away. Open the demo and press Enter the instant it appears: nothing is destroyed, because Cancel is what was focused.

A modal charges a tax. NN/g lists the bill: it demands immediate action, breaks the flow, makes the user lose their place, adds cognitive load to recover the task, and hides relevant background. "Modal dialogs that are not directly related to users' goals are perceived as annoying and can diminish trust." Before you open one, walk down this ladder and stop at the first rung that fits. Most of the time you stop before the modal.

The Popover API is the tool for overlays that must not steal the room. "Popovers created using the Popover API are always non-modal." They do not make the background inert, they do not trap focus, and the rest of the page stays interactive. MDN draws the boundary cleanly: "If you want to create a modal popover, a <dialog> element is the right way to go." A popover="auto" light-dismisses on Escape or an outside click and wires up with nothing but popovertarget on a button.

The menu above sits at its trigger with pure CSS anchor positioning, no measuring script. Name the trigger, then position the menu against that name. Inset properties (top, left, right, bottom) take the anchor() function; sizing (width, height) takes anchor-size().

/* Anchor the menu to its trigger. */
@supports (position-anchor: --a) {
  .trigger { anchor-name: --menu; }

  .menu {
    position: fixed;
    position-anchor: --menu;
    top: anchor(bottom);           /* place below the trigger */
    left: anchor(left);            /* align left edges */
    min-width: anchor-size(width); /* match the trigger width */
    margin-top: 0.375rem;
  }
}

Every one of these is a real dialog shipped broken. The native element prevents most of them; a hand-built modal has to guard against all of them.

A centered modal is a desktop shape. On a phone it usually becomes a bottom sheet, a panel that rises from the bottom edge into the thumb's reach. What changes is only the presentation, position, anchor, and entry animation. The semantics do not move. A bottom sheet is still a modal dialog or alertdialog, and it owes every one of the six requirements from Section 1: an accessible name, focus in, a trapped Tab cycle, Escape to close, focus back to the trigger, and an inert background. The same native <dialog> can present as a sheet through CSS while keeping showModal() and its guarantees.

Each rule is stated in the positive, with the reason it exists. Where the wrong turn is easy to make, a recommended and an avoid card sit side by side.