Popup and Modal Accessibility: How to Test and Fix Your Email-Capture Popup

An accessible popup or modal does three things: keyboard focus moves into it when it opens, a keyboard user can operate everything inside it and close it (Esc key plus a labeled close button), and focus returns to the page when it’s gone. Those three behaviors come straight from the W3C’s dialog pattern, and you can test all of them on your own site in about two minutes — no code required.

Most advice on modal accessibility is written for developers building custom dialogs from scratch. That’s not what most small businesses have. You have a Privy or OptinMonster popup, a Klaviyo sign-up form, or a theme’s built-in newsletter modal — installed in an afternoon, never tested with a keyboard. This guide is for that popup.

Why a marketing popup is an accessibility problem

Because it takes over the page. A modal, by definition, blocks everything behind it until the visitor deals with it. When it works, that’s fine. When it doesn’t — no visible close button, focus stuck behind the overlay, a dialog a screen reader never announces — the popup doesn’t just annoy one visitor. It stands between every keyboard and screen-reader user and your entire site.

UsableNet, which has tracked this space for years, lists the recurring failures in its pop-up accessibility guidance: popups that open without any announcement to screen-reader users, close buttons that are hard to find or unlabeled, and popup content that skips the labels and alt text the rest of the page has.

And this isn’t a niche edge case. According to UsableNet’s 2026 lawsuit-trends analysis, more than 5,000 digital accessibility lawsuits were filed in 2025, and nearly 70 percent targeted ecommerce — exactly the sites where email-capture popups are standard equipment. An overlay widget won’t save you here either; if anything, the same report found no meaningful drop in suits against widget users.

Who’s responsible when the popup plugin is inaccessible?

You are — not the app vendor. As UsableNet puts it in its analysis of third-party ecommerce tools, “Under ADA Title III, the operator of a website is responsible for the accessibility of the full rendered experience.” Vendor contracts and accessibility statements may help in procurement conversations, but they generally do not eliminate your exposure.

The vendors say the same thing, just more quietly. OptinMonster’s ADA documentation is explicit that it “doesn’t guarantee ADA compliance” — you get the tools, and the result depends on how you configure each campaign. Klaviyo’s ADA-friendly forms guide ships an accessibility assistant that flags issues like missing labels, missing alt text, and low contrast, but notes that “Klaviyo will not automatically fix any WCAG non-compliant issues.”

Read those two sentences again if you assumed the app store listing had this handled. The popup renders on your domain, in front of your customers. Legally and practically, it’s yours — the same reason Shopify stores stay responsible for their installed apps.

The 3-step popup test anyone can run

Open the page where your popup fires — in a private/incognito window, so frequency caps don’t suppress it — put your mouse away, and wait for it to appear.

1. Can you get in? Press Tab a few times. Focus should land on something inside the popup — the email field, the close button — with a visible highlight. If focus keeps cycling through the page behind the overlay, keyboard users can’t even reach the thing covering their screen, and can’t dismiss it either.
2. Can you get out? Press Esc. The popup should close. Reopen it and try the other route: Tab to the close button — it should be reachable, visibly focused, and labeled something a screen reader can announce (like “Close dialog,” not an unlabeled X). If neither Esc nor a reachable close button works, you have a trap that fails WCAG 2.1.2 No Keyboard Trap.
3. Does focus behave? While the popup is open, keep pressing Tab: focus should cycle among the popup’s own controls, not wander into the page behind it. Then close it and press Tab once more: focus should resume from a sensible spot on the page, not get dumped back at the top of the document.

Here’s what each step maps to, so you can hand results to whoever fixes it:

This is the popup-specific slice of the 10-minute keyboard test — if the popup fails, it’s worth running the full version on the rest of the page too.

Wait — isn’t a “focus trap” required?

Yes, and this trips people up, so let’s be precise. While a modal is open, the W3C dialog pattern says Tab and Shift+Tab should stay contained: focus wraps from the last element in the dialog back to the first. That containment is often called a “focus trap,” and it’s correct behavior — without it, a keyboard user tabs into a page they can’t see or click.

What WCAG prohibits is a trap with no exit. The normative text of 2.1.2 says that if focus can move to a component using the keyboard, “focus can be moved away from that component using only a keyboard interface.” For a modal, “away” means closing it: Esc works, or the close button is reachable and operable. Contain focus while open; always provide the keyboard exit. Both, not one or the other.

How to fix a failing popup in the tool you already use

Start in the popup builder’s own settings, because that’s where most of the damage is done.

In Klaviyo, open your form and check the Form Alerts tab. The accessibility assistant flags unlabeled buttons and form fields, missing image alt text, low-contrast text, and links with no discernible name — and prompts you to fix any active alerts when you publish. You can publish anyway, but that defeats the point. Klaviyo’s own doc also notes that previously published forms may still contain accessibility issues, so re-open old popups and check them too.

In OptinMonster, follow the vendor’s own ADA-compliance doc: add alt text to campaign images, label every form field, and pick colors that pass contrast checks — the doc points users to WebAIM’s contrast checker, and the 4.5:1 threshold it tests comes from WCAG 1.4.3. Add one rule the doc doesn’t spell out: keep the close button visible. Some templates let you hide or shrink it. Don’t.

In Privy or any other builder, the same configuration rules apply even where the vendor documents them less: never remove the close button, don’t rely on “click outside to dismiss” as the only exit, keep text contrast at or above 4.5:1, and label the email field rather than relying on placeholder text alone.

One more setting worth changing everywhere: the trigger. A popup that fires the instant the page loads yanks focus before a screen-reader user has heard the page. A short delay or scroll-based trigger is kinder, and it gives every visitor a chance to see the page they actually came for.

What your developer should check under the hood

Builder settings can’t fix broken plumbing, so if the 3-step test still fails, hand your developer or your web person this list from the W3C’s dialog pattern:

• The dialog container has role="dialog", aria-modal="true", and a name via aria-labelledby pointing at the popup’s heading.
• When the dialog opens, focus moves to an element inside it.
• Tab and Shift+Tab wrap within the dialog while it’s open.
• Esc closes it, and closing returns focus to the element that had it before the dialog opened.
• The close button is a real button with an accessible name — not a clickable div with a ”×” character.

If the popup is custom-built rather than a marketing app, the native HTML dialog element opened with showModal() handles Esc-to-close and makes the rest of the page inert automatically, per MDN’s documentation — which removes the two hardest bugs for free. Either way, the check that counts is the rendered result on your page — which is exactly what steps 1-3 above measure.

Test it once, then keep it fixed

A popup is the highest-stakes component on your site precisely because it interrupts everyone. Run the three steps today; they take two minutes and catch the failures that keep showing up in complaints and in real users’ abandoned sessions. Then re-run them whenever you swap templates or apps, because every new campaign is a new chance to hide the close button.

And if the popup fails, don’t stop there — a popup that traps keyboards rarely travels alone. A free accessibility scan gives you an automated baseline of what else is broken on the page behind it, in plain language, in about a minute.