Navigation

Service-Menü

Sprachversionen



Inhalt

Articles

Dynamic content
Accessible lightboxes?

15.09.2010

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 div, that is written dynamically to the page via JavaScript and often contains an image, for example the magnified view of a picture in a gallery. Increasingly often, lightboxes are also used for more complex content that formerly warranted separate pages, such as login processes or entire HTML pages presented in an iframe element.

There are many implementations and variants around that can be tied in easily via a JavaScript library such as Moo Tools or jQuery. Many of lightbox implementations, however, show serious accessibility deficiencies, for example, the inability to navigate lightbox content with a keyboard.

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.
  • When using small browser windows or displays or when JavaScript is deactivated, the content of the lightbox is often displayed in the browser window without navigational context (and, in case of images, without alternative text)
  • 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.
  • When viewing lightboxes without CSS, but with JavaScript turned on, images often appear obsured and thereby rendered useless by a dark overlay.

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.

  • When JavaScript is turned off, lightbox contents should be offered on an extra page that is a proper part of the site. The usual display in a bare browser window offers no page navigation and (in case of images) no alternative text.
    If, in line with WCAG 2.0 and the forthcoming German regulation BITV 2.0 which closely follows WCAG 2.0, it is no longer necessary to ensure that sites should still work with JavaScript turned off, this point would appear baseless. However, the principle of graceful degradation would in any case suggest that lightbox content should still be accessible with JavaScript turned off.
  • 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:
    1. 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
    2. 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.

Further information

Note: Some of the resources listed below point to not-so-accessible or inaccessible lightbox implementations.