Accessible Modals and Popups: Doing Them Right
Modals, popups, cookie banners, and newsletter overlays are everywhere. They're also a frequent source of accessibility failures. A well-built dialog works for mouse, keyboard, touch, and screen reader users. A poorly built one can make a site unusable.
First: do you need one?
Popups interrupt people. Ask whether the information could appear on the page instead. If you do use a popup, trigger it by a user action where possible, rather than on arrival or on a timer. See exit-intent popups and email signup form best practices.
What an accessible modal needs
1. A proper role and name. The dialog should be identified as a dialog, with an accessible name taken from its heading. The native HTML dialog element, opened as a modal, provides much of this for you. Otherwise use the dialog role with a label, and mark it modal.
2. Focus moves into it. When the dialog opens, move focus to a sensible element inside, often the heading, the first field, or the close button.
3. Focus stays inside. While the modal is open, Tab and Shift+Tab should cycle only within it. Content behind it shouldn't be reachable. A native modal dialog handles this, and an inert background does the same.
4. Escape closes it. Keyboard users expect Escape to dismiss the dialog, unless closing would lose important work, in which case confirm first.
5. A visible, labeled close button. Make it large enough and clearly named, for example "Close." Don't rely on a tiny "x" without an accessible name.
6. Focus returns on close. Put focus back on the element that opened the dialog, so users don't lose their place.
7. Background content is hidden from assistive technology while the modal is open, so screen reader users aren't confused by what's behind it.
8. Page scroll behaves sensibly. Prevent background scrolling without causing layout jumps.
Design considerations
- Make sure the modal works at zoom levels up to 200 percent and on small screens, without cutting off controls
- Provide enough contrast for text, borders, and controls. See color contrast
- Keep the content short and focused on a single task
- Avoid auto-dismiss timers, which can remove content before people have read it
- Respect reduced motion preferences for open and close animations. See reduced motion
- Make buttons large enough to tap. See touch target sizes
Cookie banners and consent popups
These are modals, or banners that overlay content, so the same rules apply. They must be keyboard-operable, readable by screen readers, and must not block access to the content or trap focus unfairly. Accepting and rejecting should be equally easy. See privacy policy and cookie banner basics.
Non-modal popups
Tooltips, chat widgets, and notification panels follow lighter rules, but still need keyboard access, names, and a way to dismiss. See live chat and chatbots.
Test checklist
- Opens by keyboard
- Focus lands inside
- Tab stays inside
- Escape closes
- Focus returns
- Screen reader announces the dialog and its title
See how to test with a screen reader and keyboard navigation and focus.
The bottom line
Use sparingly, build on the native dialog where you can, manage focus carefully, and always provide an obvious way out.