Introduction
Overlays are used for a variety of reasons, for example to show a larger version of an image, a notification asking for input such as login details or a method to deliver contextual information.
Su is unable to use a mouse due to tremors, and so navigates the web using her keyboard. She gets very frustrated when overlays appear on her screen. They obstruct the content she is trying to browse, and she’s usually unable to get rid of them, or interact with them in any way with her keyboard.
Accessibility issues presented by poorly implemented overlays, usually concern keyboard-only and screen reader users.
Elements of an overlay
- An overlay should be triggered by the user.
- Should appear on top of the viewed page (usually dimmed).
- Become the only element the user interact with.
Best practice for implementing overlays accessibly
- The dialog must have the appropriate WAI-ARIA roles and properties.
- Focus must be set to the dialog when it is first opened.
- Focus must be set back to the opening control when it is closed, or in another logical place in the document if the opening control is no longer present.
- Page content outside of the dialog must not be accessible to screen readers or other assistive technologies while the dialog is open.
Now let’s look at each of those a bit more closely.
The dialog must have the appropriate WAI-ARIA roles and properties
The best way to implement an accessible modal dialog is by following the WAI-ARIA Authoring Practices Dialog (Modal) pattern.
This pattern makes use of a <div> element with a role="dialog" attribute to contain the dialog content. An aria-labelledby attribute, with a value referencing the id attribute of the main heading of the dialog (which should be an <h1> as dialogs are considered to act as a separate document to the main page), with an optional aria-describedby attribute with a value referencing the id attribute of the contain element of the dialog’s content if the content is simple (one or two sentences).
Focus must be set to the dialog when it is first opened
For simple dialogs when the full content of the dialog can be referenced with the aria-describedby attribute, focus can initially be set to the first focusable control within the dialog, usually a <button> element for confirming or cancelling the action described by the dialog. For dialogs with longer or more complex content, focus can be set to the dialog container element.
Focus must be set back to the opening control when it is closed, or in another logical place in the document if the opening control is no longer present
JavaScript should be used so that when pressing the TAB key focus is kept within the dialog. On pressing TAB while focussed on the last focusable element within the dialog, focus should be set to the first focusable element within the dialog. Similarly, on pressing SHIFT + TAB while focussed on the first focusable element within the dialog, focus should be set to the last focusable element within the dialog. Pressing the ESCAPE key should close the dialog and set focus back to the opening control or another logical place in the document if the opening control is no longer present.
Page content outside of the dialog must not be accessible to screen readers or other assistive technologies while the dialog is open
All page content outside of the modal dialog must be hidden from screen readers and other assistive technologies. In theory, applying an aria-modal="true" attribute would be sufficient to achieve this, but browser support is very poor. This should be combined by applying an aria-hidden="true" attribute to all content outside of the dialog, but
not to the parent element of the dialog. This is made easier by adding the dialog as a direct child of the <body> element and applying aria-hidden="true" to all other direct children of the <body> element.
Code sample: modal dialog example
<body>
<header aria-hidden="true">…</header>
<main aria-hidden="true">…</main>
<footer aria-hidden="true">…</footer>
<div role="dialog" aria-modal="true" aria-labelledby="dialog-title" aria-describedby="dialog-description">
<h1 id="dialog-title">Modal dialog title</h1>
<p id="dialog-description">Modal dialog description</p>
<button type="button">Close</button>
</div>
</body>
Things to check
Have you?
- Checked that any links that trigger an overlay are keyboard accessible?
- Made sure than when any overlay is opened, focus is placed in a logical place within it?
- Checked focus within an overlay is visible?
- Made sure that tabbing should cycle within the actionable links inside the overlay until the user clicks a close link?
- Made the close button highly visible and obvious?
- Made sure the close button can be closed with the Escape key?
- Added appropriate alt text to any image within an overlay, especially if it is also a link that closes the overlay?
- Made sure that whenever overlay is closed, focus is returned to whatever link/or image opened it in the first place?
Resources / external links
- How to improve the accessibility of overlays (Nomensa)
- How to make modal windows better for everyone (Smashing Magazine)
Thank you for your feedback