How to create an accessible modal dialog

Love them or hate them, there is more to a modal than meets the eye.

Modals are also known as Modal Dialog, Dialog Box, Pop-up, Pop-up Window, Overlay, Alert box. Whatever you prefer to call it, there is an accessible way and a non-accessible way to add them to your website.

What are modals or modal dialogs?

Imagine you're browsing a website, and suddenly a small window appears that demands your immediate attention. You must interact with it (like clicking "OK" or "Close") before you can continue exploring the main page. That's what we call a modal dialog.

By contrast, a non-modal dialog is more like a subtle notification that pops up but doesn't stop you from doing what you're doing. You can keep interacting with the page even while it's there.

For keyboard users and those relying on screen readers, modal dialogs can be a bit of a challenge. It's super important that the website smoothly guides them to this new pop-up, and that their keyboard focus stays right there, inside the dialog. The goal is for users to always know where they are and how to move around without feeling disoriented.

How can you test if a modal is accessible?

If the thought of opening a screen reader has you running to the hills, then there is still a way for you to test whether a modal is accessible using your keyboard.

1. Do you get trapped within the modal when pressing the tab key?

Open the modal and press the Tab key repeatedly. Focus should cycle only through interactive elements (buttons, links, form fields) within the modal and should not escape to the content behind the modal.

2. Where is the initial focus when the modal is first revealed?

When the modal opens, observe where the keyboard focus lands. Focus should automatically shift to a logical element within the modal, such as the first interactive element (typically the "Close" button) or the modal's title (if made focusable with tabindex="-1").

Focus should not remain on the trigger element that opened the modal, nor should it land on an element out of view.

3. Is the focus reversed when using the Shift + Tab keys?

While focus is inside the modal, press and hold the Shift key and then press the Tab key repeatedly. The focus should stay confined within the modal and cycle backward through the interactive elements.

4. What happens when you zoom the browser’s display size to up to 200% and 400%?

The modal should remain fully visible, usable, and its content should reflow appropriately without loss of information or functionality.

5. Check for a visible focus indicator when tabbing between interactive elements?

There should be a clear, visible focus outline or style on the currently focused element.

6. Is there a way to close the modal?

When the modal opens, look for a button or link that closes the modal. Never trap a user within the modal without a mechanism to close the modal.

7. Does clicking the Escape Key close the modal?

While the modal is open, press the Escape key which should close the modal.

8. Where does the focus return when it is closed?

Close the modal (using the Escape key or a Close button) and check that focus has returned to the element that triggered the modal's opening.

Techniques to create an accessible pop-up/modal

When implemented correctly with ARIA roles and attributes, these overlays become seamless for everyone, including users relying on assistive technologies like screen readers, so let's delve into the process of building such an accessible component.

Essential ARIA Roles and Attributes

ARIA (Accessible Rich Internet Applications) provides semantic meaning to HTML elements, making them understandable by assistive technologies. For accessible overlays, the following roles and attributes are paramount:

• role="dialog" or role="alertdialog": These roles identify the element as an interactive dialog box. Use role="dialog" for general dialogs like forms or settings, and role="alertdialog" when the dialog contains important and often time-sensitive information that the user needs to be immediately aware of (similar to an alert).
• aria-modal="true": This crucial attribute indicates that the content behind the dialog is inert and should not be interacted with while the dialog is open. This prevents users from accidentally navigating or activating background elements.
• aria-labelledby="[ID of the heading]": This attribute associates the dialog with a visible heading element (e.g., an <h1>, <h2>, etc.) within the dialog. The screen reader will announce this heading when the dialog opens, providing context to the user.
• aria-describedby="[ID of the descriptive text]" (Optional but Recommended): If the dialog needs further explanation beyond the heading, you can use this attribute to associate it with a paragraph or other element containing descriptive text.
• aria-hidden="true" on background content. When the modal is open, all content outside the modal (the main page content) should have aria-hidden="true" as this hides the background content from screen readers, ensuring they don't accidentally navigate to irrelevant elements. Note that while aria-modal="true" helps, explicitly setting aria-hidden on background content is often recommended for broader browser/screen reader support, especially in older implementations not using the <dialog> element. 

Implementation steps

How your modal looks in down to you; however, it is important to use the correct HTML markup and JavaScript to update the state change when the user interacts with the modal.

HTML Structure

Create the basic HTML for your overlay. This will typically include a container for the entire overlay, a heading, the content of the overlay, and a close button. Ensure the heading is semantically correct.