--- title: "How to Write a Dialog Today: From showModal() to command and closedby" description: "You don't need to hand-roll modals out of divs anymore. This post rounds up how to write in 2026: show() vs showModal(), opening and closing with zero JavaScript via Invoker Commands, choosing who can close it with closedby, catching unsaved changes with request-close, getting results out with form method=\"dialog\", plus accessibility and animation details. Every section has a demo you can try." canonical_url: "https://neillin.com/en/blog/dialog-modern-guide/" --- > Index of every page on this site: [llms.txt](https://neillin.com/llms.txt) 2026/10/09 update: the "Edit note" demo now uses `ariaNotify()` to tell screen readers when a note is saved or changes are discarded. See section 5. -- > Up front: my tests for this post were run in Chromium. Newer features like `closedby` have uneven support across browsers, so what's true as I write this may not stay true. If I've gotten something wrong, corrections welcome. ## Intro After writing about [popover](https://neillin.com/en/blog/popover-auto-manual-hint) and [hidden="until-found"](https://neillin.com/en/blog/hidden-until-found), the next thing I wanted to round up was ``. Dialogs are probably one of the components front-end developers hand-roll most often: a `

` in the middle of the screen with a dimmed layer behind it. It looks fine, but almost everything accessibility needs has to be added by hand: move focus in, keep Tab from escaping to the page, close on Escape, return focus to the original button afterward, stop screen readers from reading the background... Each one is a chunk of code, and each one is a place to get it wrong. Native `` has been usable for years, but the last two years added several new pieces: Invoker Commands for opening and closing without JavaScript, `closedby` to choose who can close it, and `request-close`, which can be intercepted. Many tutorials still stop at "`showModal()` plus a hand-built close button," so this post rounds up how to write it today. First, here's what your browser supports: ## 1. Know the difference: `show()` and `showModal()` are very different `` can be opened two ways, and this is where most of the confusion starts: Open both, then press Tab and try the background button. The difference is obvious:

Behavior	`show()` (non-modal)	`showModal()` (modal)
Can you use the background?	Yes	No, the whole background becomes inert
Does Tab escape?	Yes	No, it moves only between the dialog and the browser UI
Escape closes it	No	Yes
Dimmed `::backdrop`	No	Yes
Shown in the top layer	No	Yes, so `z-index` and `overflow` can't cover it

In my Chromium tests, both move focus to the first focusable element in the dialog when opened, and when a modal closes, focus returns to the button that opened it automatically. You can see this in the event log. Writing `` straight into the HTML is the same as `show()`: non-modal. **Whenever people must deal with the dialog before continuing, use a modal**, not just the `open` attribute. ## 2. Open and close with Invoker Commands, no JavaScript Opening a modal used to require this: ```js openButton.addEventListener("click", () => dialog.showModal()); ``` Now [Invoker Commands](https://neillin.com/en/blog/popover-auto-manual-hint) do it, the same mechanism popovers use: ```html ``` There are three dialog commands:

`command`	Effect
`show-modal`	Opens as a modal, same as `showModal()`
`close`	Closes immediately
`request-close`	"Requests" a close: fires a `cancel` event first, which you can intercept (section 4 uses this)

Note that **there's no non-modal show command**, which is why the non-modal button in the comparison demo still uses JavaScript. Invoker Commands are supported from Chrome 135, Firefox 144 and Safari 26.2, so they're Baseline. In browsers without them, the demos in this post add these three commands back with a little JavaScript. ## 3. `closedby`: deciding who can close it "Close when clicking the backdrop" used to mean listening for clicks and checking whether they landed outside the dialog. Now there's the `closedby` attribute:

`closedby`	Backdrop click	Escape	Close button
`any`	Closes	Closes	Closes
`closerequest`	No	Closes	Closes
`none`	No	No	Closes

Without `closedby`, a modal behaves like `closerequest` and a non-modal like `none`. One detail I found while testing: `closedby="none"` blocks close requests from *users*, **not from your own code**. Calling `requestClose()` or `close()` on a `none` dialog still closes it. My recommendations: - **Ordinary info or settings dialogs**: use `any`; closing on a backdrop click is the most intuitive. - **Dialogs with forms or important actions**: keep the default `closerequest`, so an accidental backdrop click doesn't throw work away. - **Avoid none where you can**: removing Escape removes the exit keyboard users know best. If you really need it, always provide a visible close button. `closedby` is supported from Chrome 134 and Firefox 141. When I wrote this, the sources I found didn't show Safari support yet, so check [caniuse](https://caniuse.com). Browsers without it ignore the attribute and fall back to the defaults above, so nothing breaks. ## 4. `request-close`: ask before throwing away unsaved work This is the new feature I find most useful. Someone types a lot into a dialog, accidentally hits Cancel or Escape, and it's all gone. Plenty of people have been there. Try it: open it, type something, then press Cancel or Escape. Instead of closing, the dialog asks whether to discard your changes. The trick is giving the Cancel button `request-close` instead of `close`: ```html ``` Like pressing Escape, `request-close` fires a `cancel` event first. In the handler, check for unsaved content and call `preventDefault()` to stop the close: ```js editor.addEventListener("cancel", (e) => { if (hasUnsavedChanges()) { e.preventDefault(); showConfirm(); // show the confirmation inside the dialog } }); ``` A few things I handled deliberately in the demo: - **The confirmation lives inside the dialog** rather than using `window.confirm()`. The native confirm can't be styled, and it interrupts screen reader users. - **Focus moves to the confirmation when it appears**, so screen readers announce "You have unsaved changes." - **The close command doesn't fire cancel**, so the "Discard changes" button can use `close` to shut the dialog without being intercepted again. ## 5. `form method="dialog"`: getting the result out The demo's Save button doesn't use any JavaScript to close the dialog. It relies on ` ``` Submitting this kind of form doesn't send a request. It closes the dialog and puts the pressed button's `value` into `dialog.returnValue`. Read it in the `close` event to know how the dialog was closed: ```js editor.addEventListener("close", () => { if (editor.returnValue === "save") saveNote(); }); ``` Native form validation (such as `required`) still applies; if validation fails, the dialog stays open. Once the dialog closes, though, nothing on screen says "saved." Sighted users know the dialog disappearing means it worked, but screen reader users only hear focus land back on the "Edit note" button, with no confirmation that anything was saved. So after closing, the demo uses `ariaNotify()` to announce "Note saved" or "Changes discarded," which you can also see in the event log: ```js editor.addEventListener("close", () => { if (editor.returnValue === "save") { saveNote(); openButton.ariaNotify("Note saved"); } }); ``` `ariaNotify()` is a new API that asks the screen reader to speak a message directly, replacing the old trick of hiding an `aria-live` region. I've written up how to use it, its support, and a fallback for browsers without it in [Make Screen Readers Speak: Replacing aria-live with ariaNotify()](https://neillin.com/en/blog/aria-notify/). ## 6. Accessibility checklist Native `