A modal dialog needs a clear purpose, an understandable close action and a usable focus path. The native dialog element provides useful browser behavior, but adding the tag alone does not make every design accessible. Test the complete interaction in the browsers you intend to support.

This local example asks whether to discard a fictional unsaved note. It does not delete files or submit a request to a service.

How can a native modal be opened and closed?

<button id="open-note-dialog" type="button">Review discard choice</button>
<dialog id="note-dialog" aria-labelledby="note-dialog-title">
  <h2 id="note-dialog-title">Discard this unsaved note?</h2>
  <p>This example changes no stored data.</p>
  <form method="dialog">
    <button value="cancel" autofocus>Keep editing</button>
    <button value="discard">Discard note</button>
  </form>
</dialog>
<script>
  const opener = document.querySelector('#open-note-dialog');
  const dialog = document.querySelector('#note-dialog');
  opener.addEventListener('click', () => dialog.showModal());
</script>

The method=dialog form closes its containing dialog rather than sending an ordinary form request. A button's value can provide the dialog's return value. Application code would need to inspect the result and perform any real action separately.

How is showModal different from show?

ShowModal opens the dialog modally and makes the rest of the document unavailable for normal interaction while it is open. Show opens a non-modal dialog. Choose the behavior that matches the task rather than assuming every floating panel needs a modal interruption.

An ordinary disclosure or inline status message often does not need a dialog at all. A confirmation that interrupts the current task may justify one. State the reader's task first, then explain the interaction choice.

Where should focus go?

Choose an initial focus position that makes the task understandable and safe. In this example, continuing to edit is the non-destructive choice, so it is made the explicit initial target. Longer dialogs and different tasks may need a different focus decision.

Also check what happens after closing. The person should not be left at an unrelated place in the page. Native behavior is helpful, but the surrounding application can still interfere through rerendering, element removal or extra focus calls.

What does the accessible name communicate?

The dialog's name should identify the decision or task. Here aria-labelledby points to its visible heading. A name such as “popup” says little about what the person needs to do. Keep the visible heading, spoken name and action labels consistent.

Do not use a vague affirmative label like “Yes” when a clearer action is available. “Discard note” describes the consequence. It is especially useful when someone reaches the action without remembering every sentence in the explanation.

What about Escape and cancellation?

Test the native cancellation behavior, including Escape where supported, and decide how the application treats it. Dismissing a question should not be silently interpreted as agreement to a destructive action. Read the actual result or cancellation path instead of assuming that every close means the same thing.

Browser support and behavior can vary, so use the current documentation for your target environment. Do not turn a single successful desktop click into a claim that every assistive technology and browser combination is covered.

Practical checks for the sample

  • The opener is reachable and the modal has a useful name.
  • Opening places focus at the intended control.
  • Background controls cannot receive normal interaction while modal.
  • Both explicit choices and cancellation have safe meanings.
  • Closing leaves the reader with a sensible next focus position.

For a follow-up, remove the fictional discard choice and turn the panel into simple help text beside a field. Explain why an inline section may be less disruptive. A good answer considers whether the dialog is needed before discussing how to implement it.

References and next practice

developer.mozilla.org — html dialog

Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud