Modals and accessibility

Modals are a frequently used element on web pages. These components appear as overlays on the current page, preventing full view and interaction with the underlying content. They are often used for confirmation or cancellation screens, or to request additional details on a subject.

While common in design, modals can be a real challenge for keyboard or screen reader users if not properly implemented.

Opening the Modal

An essential aspect is how the modal opens. When a modal is triggered, the focus should shift to the first interactive element within it. Interactive elements include links, buttons, and form elements like input or select.

Screen readers

To ensure compatibility with screen readers, the modal should be properly identified using role="dialog" (or role="alertdialog") and aria-modal="true". This informs assistive technologies that the rest of the page is inactive while the modal is open.

In older implementations, developers often used aria-hidden="true" to hide background content from screen readers. However, this approach is more error-prone and harder to maintain, especially in complex applications, so aria-modal="true" is now the preferred solution.

Regardless of the approach, it's still necessary to manage focus and prevent interaction with background content through proper focus trapping and scripting.

ARIA roles and relationships

To make modals fully accessible to assistive technologies, it is important to correctly define their structure and semantics using ARIA attributes.

First, every modal should have a clear accessible name. If the modal includes a visible title, the container element with role="dialog" should reference it using aria-labelledby. This ensures screen readers announce the modal with its proper title.

Additionally, if the modal contains descriptive text that explains its purpose or provides context, this should be associated using aria-describedby. This allows screen readers to read both the title and the supporting description when the modal is opened.

<div role="dialog" aria-labelledby="modal-title" aria-describedby="modal-description" aria-modal="true">
  <h2 id="modal-title">Delete account</h2>
  <p id="modal-description">This action cannot be undone.</p>
</div>

Another important attribute is aria-modal="true". This indicates to assistive technologies that content outside the modal is inert (non-interactive) while the modal is open.

Difference between role="dialog" and aria-modal="true"

Although often used together, these attributes serve different purposes:

• role="dialog" defines the element as a dialog (a modal window) and provides semantic meaning to assistive technologies.
• aria-modal="true" indicates that the dialog is modal, meaning interaction is limited to the dialog and background content should be ignored.

In other words, role="dialog" tells what the element is, while aria-modal="true" tells how it behaves.

Both should be used together for proper accessibility support, especially since not all assistive technologies fully infer modality from the role alone.

Focus trapping

Keyboard users can accidentally navigate out of an open modal, which can lead to confusing interactions with elements behind the modal. To prevent this, implement focus trapping.

Focus trapping is a technique that ensures the focus remains within the modal while it is open. This way, a keyboard user cannot leave the modal until it is closed or the necessary action to close it is performed.

This technique is crucial for accessibility, as it prevents interactions with elements behind the modal and creates a circular navigation among the elements within the modal.

There are numerous articles on how to implement focus trapping in React
or Vanilla JavaScript, among other frameworks.

Escaping the Modal

Users often expect pressing the Escape key to close the modal. Therefore, it's important to implement this functionality. Additionally, when the modal closes, the focus should return to the element that triggered the modal.

General tips

To conclude, here are some general tips for improving the accessibility of your modals:

• On mobile or small devices, modals should occupy the entire screen to enhance readability. On larger screens, use an opaque or semi-opaque layer beneath the modal to improve visibility.
• Each modal should have a title explaining its functionality to make its purpose clear. The close button should be visible and large enough to be easily clicked, at least 44px by 44px.
• Use semantic HTML for all elements within the modal. The more information we provide to assistive technologies, the better.
• Prevent background scrolling when the modal is open to avoid confusion.

Conclusions

Building accessible modals requires more than just visual design: it involves careful consideration of semantics, focus management, and user interaction. Using role="dialog" together with aria-modal="true" provides the necessary context for assistive technologies, while aria-labelledby and aria-describedby ensure the modal is properly announced with meaningful information.

However, ARIA alone is not enough. Proper focus management (including focus trapping and restoring focus on close) and preventing interaction with background content are essential to create a predictable and usable experience for all users. An accessible modal should behave consistently across input methods, keyboard, screen reader, and pointer, ensuring that all users can interact with it effectively and without confusion.