How do I make pop-ups and modal dialogs accessible?

To make a pop-up or modal dialog accessible, move keyboard focus into it when it opens, give it a name, keep Tab and Shift+Tab inside it while it is open, and let people close it with a visible close button and the Escape key. When it closes, put focus back where the visitor was. That is the behaviour W3C's ARIA Authoring Practices Guide describes for a modal dialog, where the content underneath is inert until the dialog is dismissed.¹ Most broken pop-ups fail one of these steps.

What goes wrong with store pop-ups

Online stores use modals everywhere: newsletter sign-ups with a discount code, age checks, quick-view product windows, size guides, cart drawers and "are you sure?" prompts. Common problems:

• Focus stays behind the pop-up. A keyboard user keeps tabbing through links they cannot see, while the pop-up covers the page.
• Screen readers never hear it. The pop-up appears visually, but nothing tells a screen reader user it is there, so they read the page underneath without knowing a sign-up form is in the way.
• No way out by keyboard. The close button is a div with an "x" that cannot get focus, and Escape does nothing.
• A tiny close button in a corner, hard to tap on a phone.
• Lost place. After closing, focus jumps to the top of the page, and the visitor has to find their way back.
• Too big to use when zoomed. At high zoom or on a small phone, the close button or the form is pushed off screen.

The behaviour a modal needs

Focus in, focus back

W3C's guidance on 2.4.3 Focus Order uses a modal as its example: when the trigger button is activated, focus is set within the dialog; while it is open, the content outside cannot receive focus; when it is dismissed, focus returns to the button or the element after it.⁴ The Authoring Practices Guide adds detail. Focus usually goes to the first focusable element, but a dialog with a lot of text can start on its heading, and a dialog that confirms a destructive action should start on the least destructive option.¹ On closing, focus goes back to the element that opened the dialog.¹

Newsletter pop-ups that open on a timer have no trigger button. In that case, return focus to where the visitor was before it opened, so they can carry on.

A name and a role

Screen readers need to know a dialog has opened and what it is for. WCAG 4.1.2 asks that the name and role of interface components can be determined by software.⁷ For a custom modal, the Authoring Practices Guide uses role="dialog", aria-modal="true" and aria-labelledby pointing to the dialog's visible title.¹ It warns to use aria-modal only when the page behind really is blocked and visually obscured.¹

A way out

Keeping focus inside a modal is not a keyboard trap as long as people can leave. W3C's guidance for 2.1.2 No Keyboard Trap says restricting focus to part of a page is acceptable if the user knows how to "untrap" it, and its modal example is dismissed by a Cancel button, an OK button or the Escape key.³ The Authoring Practices Guide lists Escape as closing the dialog and strongly recommends a visible close button in the tab order.¹ Give that button a name such as "Close" or "Close newsletter sign-up", rather than relying on a bare "×" symbol to explain itself.

The close button also needs to be easy to tap. WCAG 2.5.8 Target Size (Minimum) asks for targets of at least 24 by 24 CSS pixels, or enough space around smaller ones, and W3C notes that targets in new content that appears on top of the page, such as a modal, are assessed.⁶

Use the native dialog element where you can

The HTML dialog element does much of the work. When it is opened with showModal(), the rest of the page becomes inert, the dialog sits above everything else with a backdrop, and it is exposed with aria-modal="true".² By default, a dialog opened this way can be dismissed with the Escape key.² MDN notes that opening a dialog with the open attribute instead makes it non-modal, and that you still need to provide a closing mechanism, ideally an explicit button, that works on devices without a physical keyboard.² Custom modals built from div elements must recreate all of this by hand, which is where most bugs come from.

Non-modal pop-ups and banners

Not every pop-up is modal. Chat widgets, "free delivery over 50" bars and slide-in offers usually leave the page usable. These do not need to trap focus, but they must not hide what the visitor is working on. WCAG 2.4.11 Focus Not Obscured (Minimum) fails if a sticky or floating element entirely hides the component that has keyboard focus. W3C names sticky headers, sticky footers and non-modal dialogs as typical causes, and says a properly built modal dialog always passes.⁵ Content the visitor opened themselves, such as a chat window, may cover focus if they can close or move past it without going back into it, for example with Escape.⁵

At high zoom, large pop-ups and fixed elements leave little room to read. W3C's guidance on 1.4.10 Reflow recommends making sticky and fixed components static at small viewport sizes, or letting visitors turn them off.⁸

Shopify and WordPress tips

• Pop-up apps and plugins. Newsletter, discount-wheel and upsell pop-ups usually come from an app or plugin, not your theme. Test each with a keyboard before you install it on the live store, and ask the vendor how their pop-up handles focus and Escape.
• Theme modals. Quick view, cart drawers and size guides are usually theme features. Check them after every theme update.
• Fewer pop-ups. Every pop-up you remove is one less thing to test. An inline sign-up form in the footer is accessible by default and does not interrupt anyone.

How to test a pop-up in five minutes

1. Load the page and wait for the pop-up. Press Tab. Does focus go into the pop-up?
2. Keep pressing Tab. Does focus stay in the pop-up, or wander behind it?
3. Press Escape. Does it close? If not, can you reach a close button with Tab and activate it with Enter?
4. After closing, press Tab once. Are you back where you were?
5. Turn on a screen reader and reload. Is the pop-up announced, with a sensible name?
6. Zoom to 400% or use a narrow phone. Can you still see and reach the close button?

An automated check catches some of this, such as a close button with no name or a dialog with no label. Jralo's free check runs axe-core in a real browser against WCAG 2.2 A and AA, and also reads your terms, privacy and contact pages to suggest which countries' accessibility laws are likely relevant, with a link to a guide for each (general information, not legal advice). Automated tools find many problems, not all, and focus behaviour is one that needs a person with a keyboard. For the keyboard pass in more detail, see how to check your website in 15 minutes.