Accessible Modals and Pop-ups: What Non-Developers Need to Know

Every site has them. The newsletter sign-up that appears thirty seconds after you land. The “Are you sure you want to leave?” confirmation when you try to close a cart. The image that expands when you click a thumbnail. The pop-up that asks whether you want the US or the UK version of the site. Modals and pop-ups have become such a default part of how the web works that most people have stopped noticing them — unless they cannot get out of one.

When we audit small business websites, modals sit second on the list of “custom widgets that almost always fail WCAG,” right behind cookie banners. The pattern looks simple from the outside. A box appears over the page. You do something in the box. You close the box. Under the hood, though, a modal has to do at least six things correctly to be accessible, and most implementations get two or three of them right. The rest are left to ship because nobody on the project tested them with a keyboard, a screen reader, or a zoomed-in browser window.

This guide is for site owners, marketers, and product managers who do not write code. You will learn what makes a modal accessible, the failure patterns we see on almost every audit, a two-minute test you can run on your own site right now, and exactly what to tell your developer to change.

What counts as a modal or pop-up

The terms get used interchangeably, but it is worth defining them before we go further.

A modal (also called a modal dialog) is a box that appears on top of the page and blocks interaction with everything behind it. The classic example is a confirmation prompt: “Are you sure you want to delete this? Cancel / Confirm.” You cannot click anything on the page behind the modal until you choose one of the options. Modals are the most common pattern for newsletter sign-ups, login forms embedded in-page, image lightboxes, and “edit profile” dialogs in admin UIs.

A non-modal pop-up is a box that appears on top of the page but does not block the rest of the page. Tooltips, notification toasts, and some cookie banners fall into this category. You can still scroll, click links, and interact with the underlying page while the pop-up is visible.

Most of this guide applies to both, but the blocking behavior of a modal creates extra accessibility requirements that non-modal pop-ups do not share. When in doubt, assume the stricter requirements apply — it is rarely wrong to make a pop-up too accessible.

The six things a modal has to do

A keyboard or screen reader user expects the following behavior when a modal opens. If any one of these fails, the modal is broken for them.

  1. It announces itself. A screen reader must know a modal has appeared. That means the modal needs a proper role (dialog or alertdialog) and an accessible name — a heading or label the screen reader can read out as it opens.
  2. Focus moves into the modal. The moment a modal opens, keyboard focus should move from whatever triggered it (usually a button) to an element inside the modal — often the first form field, the close button, or the dialog itself.
  3. Focus stays inside the modal. As long as the modal is open, pressing Tab should cycle only through elements inside it. A user should not be able to Tab past the modal and reach elements on the page behind it. This is called “focus trapping.”
  4. Escape closes the modal. Pressing the Esc key should close the modal and return the user to the page. This is not optional — it is baked into the WAI-ARIA Authoring Practices and every major screen reader expects it.
  5. Focus returns when the modal closes. When the modal is dismissed, keyboard focus must go back to the element that opened it (or to another sensible place in the page). Otherwise keyboard users are dumped at the top of the page every time they close a modal, which is maddening.
  6. The page behind the modal is inert. Content behind the modal should not be reachable by keyboard or screen reader while the modal is open. Without this, screen readers can read right through the modal into the page underneath, which is confusing and defeats the point of having a modal at all.

These six requirements correspond to WCAG 2.1.1 (Keyboard), 2.1.2 (No Keyboard Trap), 2.4.3 (Focus Order), 2.4.7 (Focus Visible), and 4.1.2 (Name, Role, Value). A modal that fails on any of these fails WCAG at Level A or AA.

The failure patterns we see on almost every audit

We have audited a few hundred modals across small business sites, e-commerce stores, and SaaS dashboards. The same handful of failures shows up again and again.

Focus is never moved into the modal. The most common failure. A modal appears, but keyboard focus stays on the button that opened it. A keyboard-only user cannot Tab into the modal unless they happen to guess at where it is in the Tab order. Many plugins and page builders (including some popular ones in Webflow, Elementor, and Shopify) ship with this default behavior.

Focus is not trapped. The second most common. Focus moves into the modal when it opens, but the user can then Tab past the last element in the modal and land on elements in the page behind it. This is especially common when developers build modals as hidden sections of the page that are simply shown and hidden rather than actually isolated.

There is no close button, or the close button is a decorative icon. A small “X” in the corner is fine visually but useless to a screen reader if it is not a real button with an accessible label. We often see <div> elements with a click handler and no label — invisible to assistive tech.

Escape does not close the modal. Often forgotten on custom implementations. This is particularly painful on cookie banners (which are frequently modal), where the only way to dismiss them is to hunt for a “Reject” or “X” button.

The page behind the modal is still reachable. When you Tab past the visible modal, you find yourself reading through the homepage. This happens when the developer forgets to set aria-hidden or the inert attribute on the rest of the page.

The modal has no accessible name. The box appears, but the screen reader just announces “dialog” with no context. Users do not know what the modal is for, what it is asking, or what their options are.

Focus is lost when the modal closes. The modal disappears, but instead of returning focus to the trigger, focus lands on the <body> element or the top of the page. Keyboard users lose their place in the content.

A two-minute test you can run right now

You do not need a screen reader to catch most modal bugs. A keyboard is enough. Open your site and find a page with a modal — a “Contact us” button that opens a dialog, a “Subscribe” pop-up, an image gallery, or a “Sign in” prompt. Then:

  1. Press Tab until the trigger button has a visible focus ring around it. Press Enter to open the modal.
  2. Did focus move into the modal? Press Tab. Does the focus ring stay inside the modal box, or does it go back to elements on the page behind it?
  3. Keep pressing Tab. Eventually you should cycle back to the first focusable element in the modal. If you exit the modal instead, focus is not trapped.
  4. Press Esc. Does the modal close?
  5. After it closes, where is focus? Press Tab once and look for the focus ring. It should be on or next to the button that opened the modal.

If any of those five steps fail, your modal has a WCAG violation. Most modals fail on at least two of them.

For the full screen reader experience, use VoiceOver (Cmd-F5 on a Mac) or NVDA (free, Windows) and listen to what happens when the modal opens. It should announce the modal’s name or heading. If it says only “dialog” or nothing at all, the accessible name is missing.

What to tell your developer (or page builder)

If your developer wrote the modal, the fix depends on the framework, but the instructions you want to give them are the same regardless of stack:

  • Use a real <dialog> element or set role="dialog" on the modal container.
  • Give the modal an accessible name using aria-labelledby pointing at the heading inside it.
  • Move focus into the modal when it opens. The first focusable element, the close button, or the dialog itself are all acceptable targets.
  • Trap focus inside the modal while it is open. Most UI libraries have a focus-trap utility or hook for this.
  • Close on Esc. Close on clicking the background overlay (optional but expected).
  • Return focus to the element that triggered the modal when it closes.
  • Mark the rest of the page as inert while the modal is open, or at minimum set aria-hidden="true" on the main content.
  • Make the close button a real <button> with a visible or aria-labeled “Close” text.

If your modal comes from a plugin, theme, or page builder, the answer is usually to replace it with a better-known accessible component rather than patching the existing one. Common accessible alternatives include Radix UI Dialog, Headless UI Dialog, Reach Dialog, and the native HTML <dialog> element (which is now supported in all major browsers and handles most of the list above automatically).

If your site is on Shopify, Squarespace, or Wix, start by auditing which modals are built in and which come from third-party apps. The built-in product quick-view and cart drawer modals have improved significantly since 2024, but most email capture and upsell apps have not. Swapping an inaccessible app for an accessible one is often cheaper and safer than hiring a developer to patch it.

Pop-ups specifically: the timing question

Non-modal pop-ups — the “10% off your first order” box that appears ninety seconds after landing, or the exit-intent pop-up that fires when you move your cursor toward the close button — have an additional accessibility concern beyond the six we listed: timing.

WCAG 2.2.1 (Timing Adjustable) requires that if a pop-up appears automatically and has a time limit, the user must be able to extend, disable, or turn off the limit. WCAG 2.2.2 (Pause, Stop, Hide) applies to moving or auto-updating content. And from a usability angle, auto-firing pop-ups that cannot be dismissed with a single keystroke are the top complaint we hear from users with motor disabilities, who often struggle to hit a small close button in time before it animates away.

If you run time-based pop-ups, make sure the close button is reachable by Tab, works with Enter, is dismissible with Esc, does not disappear on its own, and is at least 24x24 CSS pixels (to satisfy WCAG 2.5.8 Target Size).

The bottom line

Modals and pop-ups are one of the highest-leverage accessibility fixes on most sites because a single broken modal can block a newsletter signup, a checkout confirmation, or a support form for every keyboard and screen reader user who visits. The two-minute test above will tell you in a single session whether your site is in trouble. If it is, start with the modals in your conversion path — signup, login, cart, checkout — and work outward from there.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.