Concepts of the web platform can sometimes be quite different, yet seem very similar. Semantics, behaviours and characteristics are different things, even if they are sometimes combined into one thing. As a new popup attribute is in the works, this post will go into the differences between dialogs, modals, overlays, popups, disclosures and full screen content. All somewhat related concepts that can seem very similar. Let's dive in!

The thing with words and concepts is that they can mean different things to different people in different places and times. The concepts in this post are no different. I noticed that browsing some older resources, like the WHATWG wiki on dialogs. For clarity, throughout this post, I will refer to the concepts of dialogs, modals and popups as they exist in standards like HTML, CSS and ARIA. The definitions here are meant to align with the relevant specifications first and foremost, and with individual team's naming conventions second.

Below, we'll start with a bunch of characteristics: things components can have, like modality, light dismiss, top layer presence and backdrops. Then we'll talk about what we get when these characteristics are used together: dialogs, popups and disclosures.

The characteristics

Light vs explicit dismiss

One major difference between these components is in how users would dismiss them and whether that is affected by other elements.

‘Light dismiss’ is the main feature that popups bring to the table, you only get it when you make an element a popup.

Modality / inertness

The web platform has this concept of content being ‘inert’: it means that you cannot interact with the content. It is only really there visually, but you can’t do anything with it.

When an element is in a modal state, it is the only thing that can be interacted rest with and the rest of the page or application should be inert. You should not be able to tab to anything outside of the modal element, or scroll in content outside of the modal.

Elements that are not modal are called non-modal or modeless.

Top layer presence

By default, if multiple elements are positioned in the same location, they are painted by the browser in layers. This is done in DOM order: the element that is first in the DOM is painted first, each subsequent element on top of the previous and the last one in the DOM is painted last, at the top. With the `z-index’ property in CSS you can deviate from the default on a case by case basis, and decide your own layer order.

The top layer is a special layer that is, as the same suggests, always on top.

Popups are in the top layer when they are of the ‘manual’ type

Dialogs are not.

Backdrop

In some cases, it makes sense for elements to have a backdrop, usually this is done when they overlay the page.

With the ::backdrop pseudo element, you can optionally add a backdrop to your popup or modal dialog. This is done when they are modal, as in that case, none of the stuff behind the element can be interacted with. A backdrop gives a visual cue for that behavior.

A backdrop obscures content behind it and is used as a visual cue that this content is unavailable, in combination with a method to actually make it unavailable (inert).

I'll say overlay is another word for an element that has a backdrop.

Trapped focus

Sometimes focus should return to the “invoking element”. A popup will return

Sometimes focus is trapped:

• traps focus if it is opened with showModal(), but not if it is opened with show() (via https://whistlr.info/2021/in-defence-of-dialog/)
• popup does not

‘Not for recreating dialog’ - Scott https://github.com/openui/open-ui/issues/415#issuecomment-1261565368

Keyboard closability

In general. things that can open would e

The main concepts

• Dialog
• Alertdialog
• Modal
• Popup
• Aria-haspopup

Dialog

The <dialog> element is something a ‘user interacts with to perform a task’ (see: dialog spec). It's often displayed when users need to choose. Do you want to continue, yes or no? If you want to open a new file, what shall we do with your current file, save or delete?

Dialogs are a lot like window.confirm() and friends, which the HTML specification lists under ‘simple dialogs’. They do offer more flexibility—you get to put whichever content and styling you want inside of them.

You can even put a form with `method="dialog"' in a dialog, which will close it when submitted.

Dialogs have a role of dialog, which the browser will assign automatically for you when you use the <dialog> element.

Dialogs can be modal (when shown with dialog.show() or non modal (when shown with dialog.showModal()).

Alert dialogs

WAI-ARIA defines a specific type of dialog, which is called “alert dialog”. It is meant for dialogs that contain brief, important message and They need to alert the user, which the browser should fire as a system alert event to accessibility APIs.

Examples

• After you didn't interact with your online banking environment for 10 minutes, and alert dialog shows and tells you you will log out in 5 minutes, unless you press “Continue my session”

Characteristics

Alert dialogs are always modal and have their focus trapped. They also require an accessible name. If there is a visible title, the title's id can be associated with the alert dialog's aria-labelledby attribute. If not, aria-label can be added to the alert dialog.

Popup

Popup is a set of behaviors that can be added to any element through the popup attribute (like tabindex or contenteditable). At the time of writing, it isn't in the HTML specification yet, but there is the Pop Up API Explainer and a PR to the HTML spec.

The popup attribute is meant for UI components that are:

• on top of other page content
• not always visible (eg just when they are relevant)
• usually displayed one at the time

An example of a popup is the listbox that shows when a select is opened (conceptually for <select> and literally for <selectmenu> as it is currently implemented in Chromium). Datepickers, teaching UI, tooltips and action menus are all examples of popup-like behaviors.

Example of a popup: Twitters alternative text feature (implementation has accessibility issues)

Popups have ‘light dismiss’ behaviour, meaning they close by themselves, except when they are of the “manual” type. Manual popups could be things like a “toast” notification that is dismissed via a timer or manual button.

Popups also can be opened, closed and toggled without JavaScript: with a <button> in HTML and popupshowtarget, popuphidetarget and popuptoggletarget attributes whose values correspond with the popup's ID, the browser can take care of showing, hiding and toggling.

An example:

<button 
  type="button" 
  popuptoggletarget="datepicker"
>Pick date</button>
<div popup id="datepicker"></div>

(the div is made a popup with the popup attribute, the button toggles the popup with popuptoggletarget)

Popups don't have a default role, . Sometimes they could be dialogs, so you would use <dialog popup>,

So, in summary: popups are a behaviour that gets added as an attribute to any element. It brings light dismiss, toggling with or without JS an

Note: Don’t confuse popup with aria-haspopup, which was deprecated in ARIA 1.2, can be a dialog, menu or other things. It requires developers to implement a focusable trigger and browsers to send an alert.

Disclosure widgets

Elements that show and hide things are often called ‘disclosure widget’, as Adrian Roselli describes in [Stop using ‘popup’]](https://adrianroselli.com/2020/05/disclosure-widgets.html). Adrian describes disclosure widgets in more detail in his aptly named post Disclosure widgets.

Disclosure widgets exist in HTML as <details>/<summary>, but can also be built with <div> and the appropriate ARIA attributes. This isn't entirely the same. In Details/summary, again, Scott O'Hara suggests that this is more consistent:

If your goal is to create an absolutely consistent disclosure widget behavior across browsers, i.e., ensuring that all `

s are exposed as expand/collapse buttons, then you’d be better off creating your own using JavaScript and the necessary ARIA attributes.

But, he adds, your ARIA disclosure widget won't have some of the features <details>/<summary> brings, like in-page search (Chromium triggers a <details>'s element open state when an in-page search query is found in its content).

• A dialog is modal when opened with dialog.showModal() and not modal when opened with dialog.show(); with popups, non modal dialogs are probably going to be obsolete (@@@)
• Full screen elements are modal when

Gotchas

Dialog node vs document mode

If you use <dialog> or role="dialog", assistive technologies will switch to application mode when the dialog is opened. This can make it so that some users can't access browse structured content in the way they are used to (eg browse byy heading or lists). For this reason, it is recommended to wrap any structured content inside of an element with role="document", like so:

<dialog>
  <div role="document"></div>
</dialog>

Source: https://github.com/twbs/bootstrap/issues/15875#issuecomment-75668416

Hidde's open questions

• is a tooltip a popup? [yes ?]
• is a cookie banner a dialog?
• chat popup

https://developer.apple.com/design/human-interface-guidelines/guidelines/overview

Summing up

---

Originally posted as A dialog, a modal and a popup walk into a bar. How are they different? on Hidde's blog.

Reply via email