How To Build Accessible Exit-Intent Modal Popups
Exit-intent popups try to catch your attention right as you’re about to leave a page. They’re great for “before-you-go” offers—but they’re often built around mouse movement, which leaves a lot of people out. Here’s a practical, human-friendly guide to make them both accessible and inclusive.
What’s an exit-intent popup, really?
It’s just a modal that opens when your code thinks you’re leaving—usually when the cursor rockets toward the top bar. On phones (no cursor), teams fake it with scroll or time-on-page. The key bit: you trigger it, not the user.
Why it matters for real people
Keyboard-only / switch / voice users: Pointer tricks don’t run for them, so they may never see the offer unless you provide another way.
Screen reader users: A surprise overlay without proper dialog semantics is basically invisible… or worse, a focus trap.
Folks with cognitive sensitivities: Sudden popups can be jarring and derail the task.
Mobile users: Exit-intent doesn’t map well to touch; back-button hijacks feel hostile.
Bottom line: Done wrong, it overwhelms a few and completely skips others.
How to spot problems fast
Try these quick tests to see if your modal is accessible:
Keyboard only: Reload, use Tab/Shift+Tab/Enter/Escape. Can you open the offer at all? If it opens, does focus move into the modal? Can you close with the Escape key and a visible “Close” button? Does focus return to where you were?
Screen reader (desktop): With NVDA/JAWS/VoiceOver, open the modal. Do you hear “dialog” and a clear title? Can you tab only inside it?
Mobile check: Don’t block the back gesture. Consider using an inline banner instead of a modal on small screens.
Step-by-step: build it accessibly (without the chaos)
1) Don’t rely only on “exit”
Keep exit-intent as one trigger among several:
Add a normal CTA button (“Get 10% off”) that opens the exact same modal.
Consider “scrolled 75%” as a gentle, second-chance trigger.
On mobile, prefer a non-modal pattern (inline banner, toast, or sticky footer).
2) Use proper dialog semantics
Wrapper: role="dialog" (or role="alertdialog" only if truly urgent) + aria-modal="true".
Give it a visible title and hook it up: aria-labelledby="dialog-title".
Optional helper text: aria-describedby="dialog-desc".
3) Manage focus like a pro (it’s 80% of accessibility)
On open: move focus into the dialog (title or the first field).
Trap focus: Tab/Shift+Tab should loop inside the modal.
Escape key closes and returns focus to the thing that opened it (your CTA button).
4) Make the background inert
While the dialog is open:
Prevent background tabbing. If your framework supports the inert attribute, set it on the page wrapper. Otherwise, add aria-hidden="true" to siblings and remove it on close.
Prevent scroll “bleed” (lock the body scroll).
5) Respect people’s choices
If a user closes it, remember that in localStorage/cookies and don’t pester again for a while (ex: 7 to 30 days).
Don’t re-show on every page view or on tiny wiggles of the mouse.
Keep motion subtle to avoid dizziness (no giant zooms or bouncy entrances).
6) Mobile rules of thumb
Avoid modals if you can; use a dismissible inline promo.
Never hijack the Back button.
Keep controls large enough for touch, with visible focus for external keyboards.
7) Quick WCAG mapping (what you’re likely to hit)
2.1.1 Keyboard (A): Must open, use, and close by keyboard. Also provide a non-pointer way to discover it (the CTA button).
2.4.3 Focus Order (A) & 2.4.7 Focus Visible (AA): Focus goes in, stays visible, returns on close.
1.3.1 Info and Relationships (A) & 4.1.2 Name, Role, Value (A): Correct dialog roles, titled headings, labeled inputs, named Close button.
2.2.2 Pause, Stop, Hide (A): Let users dismiss and keep it dismissed.
8) Keep it healthy over time
Centralize the modal as one reusable component. Test it for: focus in/out, dismiss, trap, labels, inert background.
Add analytics to watch show rate, close rate, and frustration signals (instant closes).
Keep content short, benefit-first, and don’t gatekeep basic info behind the popup.
Helpful next steps (no pressure)
Want to sanity-check your modal in minutes? Try Wally’s WAX Chrome Extension or Wally WAX Linter for VS Code to flag dialog roles, focus traps, and keyboard gaps right on your site. Or run a quick audit below and we’ll hand you a drop-in, accessible modal pattern that still converts.
Want your ‘before-you-go’ offers to work for everyone? Grab a free Wally accessibility check, or chat with us about training so your next pattern ships accessible by default.
