Lightboxes have become widespread. Where once we would see a new window or a system dialogue pop up, we now see the background darken and a lightbox unfold. Can lightboxes be implemented in an accessible way?
Technically speaking, the lightbox is simply a container, like a
Problems when using lightboxes
A number of problems frequently appear when lightboxes are used:
- There is no standard behaviour for the keyboard navigation of lightboxes. Some implementations show the current focus and react to keyboard shortcuts, others don't. What actually works and what doesn't has to be established empirically by the user.
- Users of screen magnifying software often find the sudden appearance of lightboxes disruptive and disorienting: they may not or only partly appear in the magnified area.
- Sceenreaders will often not read lightbox content unless a script explicitly moves the focus to the new content and that requires some skill to implement reliably (compare WAI-ARIA Best Practices: 3.2.1. Using Tabindex to Manage Focus among Widgets).
- The browser's back button doesn't work since the lightbox content is not a new page. Whoever tries it will end up on the previous page.
- During keyboard navigation the focus often accidentally moves to the darkened background where it is no longer visible; to close the lighbox, it has to be moved back (the user watching out closely for its reappearance) or moved forward through the entire dimmed page.
- Often after closing a lightbox, the old focus position on the page is lost and has to be reestablished.
- Lightbox contents are often appended at the end of the page, which means that the content order is at best confusing when viewed without CSS or when using custom stylesheets.
Recommendations for lightbox implementation
Despite the problems mentioned there is no need for an outright rejection of lightboxes if they are implemented in an accessible manner. Surely it makes sense to assess whether it is not possible or even preferable to do without them. If you have to use them (for example because the client demands them), we can think of a few recommendations.
- Every lightbox should at least have a keyboard-accessible 'close'-link; additional links should of course also be keyboard-accessible. Upon opening the lightbox, the focus should be set to the beginning of its content. When closing the lightbox, the old page focus should be restored.
- It is important to ensure a clear and intuitive focus order for keyboard navigation. Most importantly, it should be easy to close the lightbox. Two approaches for this seem appropriate:
- when a user tabs on after reaching the last focusable element in the lightbox, the box closes by itself and the old page focus is restored; or
- while the lightbox is open, the focus just moves around its links until the user actively closes the box (by activating the 'close'-link or hitting escape).
- All focusable lightbox elements should clearly show the current focus.
- If the escape key closes the lightbox, this behaviour should be documented in the lightbox itself.
Note: Some of the resources listed below point to not-so-accessible or inaccessible lightbox implementations.