Stop Using ‘Pop-up’
TL;DR: Stop using the word pop-up. Instead choose a term that accurately describes the control you want.
I encourage you to read my post Stop Using ‘Drop-down’, which provides the set-up for this post. Along with another term I would prefer everyone stopped using.
As you embark on a design, build, or specification, it is important you, the stakeholders, and the team understand what you are producing and why. When you say pop-up, which one of the following terms or concepts do you mean? What about your client? Your designer? Your developer? The user (who calls the help line)? The screen reader? The voice control software?
1. New Window
These generally come in two types: marketing wants to keep its bounce rate down so they make you add
target="_blank" to all outbound links (do not do this); or you launch windows to hold helpful information, such as glossaries or tutorials for the screen at hand.
In each case these are browser windows. Even if they only open a new tab (really not practical in the second case), they are still are stand-alone documents in a stand-alone browser document interface.
If your intent is to open a new browser window, then call it a new window.
2. Browser Dialog
Relying on the browser to generate messages and/or ask for feedback using native browser dialogs has fallen out of favor. Partly because of security risks, and partly because a brand cannot control the design.
window.confirm() (when a needy site asks if you really want to go), or
window.prompt() (as I use in my Reading Order Bookmarklet).
If you are referring to this construct, call it a browser alert dialog, browser confirmation box, or browser prompt dialog, depending on which you choose.
This is something you build from scratch (or your chosen library does) to place content over the page (on the z-index), preventing interaction with the underlying page until the user completes a task or the page decides it is done shoving that in the face of the user.
You would be aware you are building this because you have to give it an appropriate ARIA role and accessible name, manage the focus, usually have some way to dismiss it, and “gray-out” or “dim” the content behind it.
To refer to this pattern, call it a modal dialog.
You may know this by another name, depending which of 44 design systems you are using. Variations on toast include alert and notifications, along with less IBM-ish noty and growl (for the pre-OSX days of Macs). Their behavior is nearly as variable as their names.
Essentially it is a message that appears over the page (z-index), without preventing interaction with the page, that generally removes itself after some inappropriately short amount of time. While toasts may be very tricky to get right, you would be wrong to call them pop-ups. Or Pop-Tarts®.
To refer to this pattern, call it a toast.
5. Disclosure Widget
Think of this as the ARIA version of
<summary>, but in this case you are not using ARIA roles to enhance generic controls. You need a
aria-controls despite falling support) and an associated content container whose visibility is toggled.
The disclosure widget pattern is simple in HTML and script. If you have the visible content appear higher up the screen than your other content, it is almost literally popping up. The pattern is robust and can even be used for navigation.
Use the term disclosure widget to refer to this pattern.
This generally describes what appears when the user hovers their mouse over something, like an info icon, or column header, or a button. Sadly, using this tells keyboard users, voice users, and touch users they can all get stuffed (yes, even when you use the
title attribute). Which is exactly why you shouldn’t use this (anti-)pattern.
For this scenario, knowing it comes with a series of accessibility risks, call it a tool-tip.
If your team has sworn off tool-tips, but someone higher than you (in the check-writing chain, because clearly not in morality) insists on something like it anyway, you can use a simple disclosure widget to potentially fill that gap.
Essentially your pattern looks like a tool-tip, except you have to activate it manually. Screen reader users can be given a bonus freebie announcement of what it contains, but only do that if you have tested it with them and they are down with it. I made an example toggle-tip in a Twitter fight, but it is not production ready.
For this scenario, call this disclosure widget a toggle-tip.
8. ARIA Menu
If you are re-creating native operative system controls, like the File menu in Microsoft Word, then the ARIA Authoring Practices menu or menubutton patterns may do the job for you. Certainly do not use those for site navigation.
But if you are building a native application and your screens are part of a web view, then these may fit.
You can get away with referring to either option as an ARIA menu.
9. Fly-out Navigation
Web site navigation has been referred to as drop-downs for years, even though some of my clients refer to them as pop-ups. I don’t know why.
If you are looking for navigation where tabbing or mousing through the top-level options reveals nested options, then you need a more accessible pattern. WAI provides tutorials for assorted patterns, and the term Fly-out Menus fits. It is not a new term, existing since before the Suckerfish navigation that was all the rage in the early aughts.
If you have navigation that generally fits this pattern, refer to it as fly-out or fly-out navigation.
This is on the list only because VoiceOver (both macOS & iOS) and TalkBack (Android) will refer to a
<select> as pop-up button. JAWS and NVDA refer to it as combobox. Screen reader users may use that term, so when working with them you will need to understand that word difference.
If your intent is to reference a native HTML
<select>, then call it a select.
11. Custom Display Selector
This is sort of a catch-all. I have seen developers come up with all methods of making controls that essentially work by hiding some stuff, then showing that stuff by animating or popping some container into existence. These are generally inaccessible and this might be a great opportunity to make sure you choose something that conforms to one of the patterns above.
If you find yourself venturing into this territory, probably stop. Go back and figure out what the requirements truly are, as opposed to relying on assumptions or a weird desire to invent a new pattern that nobody will understand.
When discussing this approach, call it consulting.
I kinda hope you just had a record scratch moment. Because yes, there is now such thing as popup (no hyphen). Sort of. In January 2021, a team lead by Microsoft proposed a new element —
I was immediately curious, and waded into the issues on GitHub to ask questions, challenge some assumptions, and probably panic a little. The content has since migrated over to OpenUI as Enabling Popups, Initial Explainer. You can also get involved, especially by weighing in when asked (such as this question about anchored positioning use cases where you can speak up on GitHub).
If you are talking about this effort, or this is the far future and the effort resulted in a
<popup> element being minted, refer to it as popup. Or pop-up. I still use a hyphen.
If someone asks for a pop-up, you first have to disambiguate (hey, a Wikipedia word!) between a dialog-like thing, a form control, or display widget thing. Then you need to be diligent in what terms you use. Even with a dialog-like thing, what they expect may be a function of how long they have been online.
If they ask for a pop-under, show them the door.
Stop using the word pop-up. Instead choose a term that accurately describes the control you want.
Does the term “pop-over” refer to tool-tips?
When pop-under windows were a (terrible) thing, pop-overs meant normal windows or even dialogs (at least for the marketing agency clients of mine). I have also seen pop-over used for modals, tool-tips, toggle-tips, and toasts. In short, I would work with whomever to disambiguate that term whenever it comes up. This post could hopefully help with that.