A visitor lands on your site and, three seconds later, a “Save on your first order” box slides over the page. With a mouse, they hunt for the little X and move on. With a keyboard, they press Tab and focus wanders off behind the box, onto links they cannot see. With a screen reader, they may not know the box appeared at all and keep reading a page that is now covered.
Modal popup accessibility comes down to a short list of behaviors: where focus goes when the popup opens, whether it stays there, how the visitor closes it, and where focus lands afterward. Get those right and most popups become usable. This post walks through each one, then looks at newsletter and promo popups, which are where most WordPress sites run into trouble.
What counts as a modal
A modal is any window that sits on top of the page and expects you to deal with it before going back. Signup boxes, “are you sure?” confirmations, video lightboxes, image galleries that open full screen, login boxes, age checks and store location pickers are all modals.
Not every popup is modal. A small banner along the bottom that leaves the page usable, or a tooltip, is non-modal. Those have their own rules, mostly about not covering things, and are simpler. This post is about the full overlay kind, where the page behind is dimmed or blocked.
Four behaviors behind modal popup accessibility
1. Focus moves into the popup when it opens
When the modal appears, keyboard focus should move inside it. Usually that means the first interactive element, such as the email field, or the dialog’s heading if the content needs reading first. If focus stays on the button that opened it, or worse, at the top of the page, a keyboard user has no idea where the popup is in the tab order.
2. Focus stays inside while it is open
While the modal is open, pressing Tab should cycle through the controls inside it and wrap around, and Shift+Tab should go the other way. Focus should not escape to the dimmed page behind. This is what people mean by “focus trapping”, and here it is wanted. A modal is supposed to hold focus until it is dismissed.
There is a difference between this and the keyboard trap that WCAG 2.1.2 forbids. A good modal holds focus but always gives you a way out. A bad one holds focus with no working close control, which is exactly the trap the criterion describes.
3. Escape closes it, and so does a visible button
The Escape key should close the modal. There should also be a close button that is a real button, reachable by keyboard, with a name like “Close” or “Close signup form”. An X icon alone is read as “button” or nothing. Clicking the dimmed backdrop can close it too, but that only helps mouse users, so it cannot be the only way.
4. Focus returns to where it came from
When the modal closes, focus should go back to the element that opened it. If someone pressed “Watch video” and closed the lightbox, they should be back on “Watch video”, not thrown to the top of the page. For popups that open by themselves, return focus to a sensible spot, usually where the person was before it appeared.
Telling screen readers it is a dialog
The native HTML dialog element, opened with its showModal() method, handles a lot of this for you in current browsers: the page behind becomes inert and Escape closes it. Custom builds use role="dialog" with aria-modal="true", and either way the dialog needs a name.
<div role="dialog" aria-modal="true" aria-labelledby="nl-title">
<h2 id="nl-title">Join our newsletter</h2>
<label for="nl-addr">Your email</label>
<input id="nl-addr" type="email">
<button type="submit">Subscribe</button>
<button type="button">Close</button>
</div>With that in place, a screen reader announces something like “Join our newsletter, dialog” when focus moves in. Without it, the person hears a form field with no context and has to guess what happened.
The page behind should also be hidden from assistive technology while the modal is open, so a screen reader cannot wander back into it with its own reading commands. The native dialog and the inert attribute both do this.
Newsletter and promo popups
Marketing popups are the ones least likely to be accessible popups. They are usually added by a plugin and styled to stand out, and few people test them beyond a glance. The usual problems:
- The close button is faint or tiny. A light gray X on white often fails 1.4.11 Non-text Contrast, and a 12 pixel icon is below the 2.5.8 Target Size minimum unless it has space around it.
- The email field has only a placeholder and no label. Once someone starts typing, the hint disappears, and some screen readers do not read placeholders reliably.
- The success message is not announced. After submitting, the form swaps for “Thanks!” but nothing tells a screen reader user it worked. That is a WCAG 4.1.3 Status Messages issue.
- It reopens on every page because the “do not show again” setting is not saved, so a keyboard user has to fight through it each time.
- It appears while someone is filling in another form, stealing focus mid-word.
- It has a countdown timer that nobody can pause or extend, which pressures exactly the people who read or type more slowly.
Timing and triggers
When the popup appears matters as much as how it is built. A popup on page load gets in the way of everyone, and for screen reader users it can arrive before they have understood the page. Exit-intent popups rely on mouse movement and do not fire for keyboard users at all, which is not a barrier in itself but means you are not reaching them. Triggers after scrolling or after a delay are generally gentler. Always let visitors close the popup and stay closed.
If you are setting one up from scratch, our guide on adding a popup to WordPress covers the general options, and if yours already refuses to go away for anyone, see fixing a WordPress popup that will not close. The form inside the popup deserves the same care as any other; our accessible form fixes cover labels, errors and success messages.
Lightboxes, galleries and video popups
Image lightboxes and video popups are modals too, and they often get the four behaviors partly right. Things to check:
- Open the lightbox with Enter on the thumbnail link. Does focus move into it?
- Can you reach next and previous with Tab, and do they have names?
- Does each image in the lightbox have alt text, or does it only show the file name?
- Does Escape close it, and does focus return to the thumbnail you opened?
- For video, can you reach the player controls, and are captions available?
Many theme and gallery lightboxes skip step four. It is a small fix, and someone browsing twenty photos in a row will feel it on every one.
Cookie notices are a special case
Cookie consent banners are popups too, and sometimes full modals. They raise extra questions about whether they block content, where they sit in the focus order and how clearly the choices are worded. Those are covered separately in our post on accessible cookie consent banners.
Testing your own popups
You can check most modal popup accessibility problems with nothing more than a keyboard. Trigger each popup on your site, then: press Tab and see where focus goes; Tab around the inside until it wraps; press Escape; check where focus ends up. Then try it at 200 percent browser zoom, where popups often overflow the screen and the close button ends up out of reach. A step-by-step version of this kind of check is in our keyboard accessibility testing guide.
For a screen reader check, NVDA on Windows is free and VoiceOver is built into every Mac. Open the popup and listen: is it announced as a dialog, with a name? For where popups fit among all the other fixes on a WordPress site, see our guide to a more accessible WordPress website, and for audits, fixes and monitoring in general, our ADA website accessibility help page is the starting point.
Frequently asked questions
Are popups bad for accessibility?
Not by nature. A popup that moves focus inside, keeps it there, closes with Escape and a labeled button, and returns focus afterward can work well for keyboard and screen reader users. Trouble starts when popups appear without warning, cannot be closed by keyboard, or keep coming back on every page.
Is trapping focus in a modal allowed?
Yes, when it is done properly. Holding focus inside an open modal is the expected behavior, because the page behind is not usable. What WCAG forbids is a trap with no way out. As long as Escape and a reachable close button both work, keeping focus in the modal is correct.
Should a popup close when you click outside it?
It can, and many people expect that. But it must not be the only way to close it, because keyboard and screen reader users cannot click the backdrop. Always provide a visible, named close button and support the Escape key as well.
Do popup plugins handle accessibility for me?
Some popup plugins handle parts of it, such as Escape to close or focus moving in. Others do very little. Behavior can also change with your theme and settings. Test every popup you publish with a keyboard and, ideally, a screen reader before relying on the plugin’s claims.
Popups, lightboxes and the forms inside them are part of what we test and repair when working through a WordPress site. If you want yours checked and fixed, see our WordPress accessibility service.
Next in this series: Cookie Banner Accessibility: Keyboard, Focus, Wording
