Specification for an Accessible Lightbox
Published: Dec 16th, 2011 | 6 Comments
Lightbox or pop-up panel functionality is very popular on sites these days. It’s a way of showing extra information on a page without having to move away from the page.
However one problem of using lightbox functionality on a site is that most implementations are not fully accessible, and for some people the functionality can appear to break the site.
This post looks at key accessibility and usability problems with most lightboxes and proposes a specification for an improved lightbox that could work for everyone.
What is a lightbox?
Traditionally the term lightbox refers to a physical container containing light sources that can be used to view photographic slides or x-ray films. Stock photography websites also often use the term to refer to a collection of stored images. See Wikipedia for a full list of definitions for the term.
The term is also used on the web these days to refer to functionality which pops open a panel seemingly above the main content of a web page or application. Typically the functionality is used to show a larger version of an image, but occasionally the panels shown can contain other content like logon forms or context sensitive help.
It is this latter form of lightbox that this post is concerned with.
Why people use them?
I can see that lightboxes to display large versions of images can be useful. Placing thumbnail images in a page rather than the full size image can reduce the download weight of a page and so speed up its time to load – especially useful when sites are viewed on a mobile phone. Also, using a lightbox it is possible to present much larger images to users than might fit within the constraints of the page design.
I myself would hesitate to use lightbox panels to present other content – including form fields. The accessibility issues covered in this post might mean that key functionality of a website might be hard or impossible for some to reach.
So what are the problems with using lightboxes?
Typical lightbox accessibility issues
Triggering the functionality from a mouse whilst hovering over one of the thumbnail images presents no problem at all.
The problems start when using a keyboard to interact with the functionality. It is possible to tab around the example page and focus will arrive at one of the thumbnail images.
Assuming that users can see where focus is they can use the enter key to trigger the opening of the lightbox to show the larger version of the image. The issue now is that the keyboard focus has not been moved and it still sits on the thumbnail image. But the main page has been mainly obscured by the large image and the semi opaque layer that has been placed on top of it and so the focus is very hard to determine – even in browsers which try to highlight keyboard focus.
This particular lightbox can be closed by pressing the Escape key but there is nothing on the screen to tell you that.
The result is that a user will think that the page or site is unusable. If users perceive a site to be broken they are likely to abandon it and worse still, tell others that it’s broken and not useful.
So what can be done to rescue the situation?
A truly accessible lightbox?
Keyboard users as well as mouse users
As we’ve seen, one of the key accessibility issues with lightboxes is that they are seldom easily accessed/operated by keystrokes.
So the two key requirements here are:
- Focus should always be visible when users tab round a page
- For the action to be triggered by the enter key as well as a mouse click. This means that whatever triggers the lightbox will need to be able to get keyboard focus – so typically it’ll need to be a link or a button.
Once the lightbox is open it is vital that focus is placed into the lightbox to enable keyboard users to successfully interact with the lightbox controls (close, next image, etc). Almost all lightboxes on the web fail to do this – which can completely destroy a page’s usability for keyboard users.
Tabbing beyond or before the lightbox controls has to be catered for as well. There are two options here:
- Focus should cycle around within the lightbox panel until it is closed.
- Tabbing before or after the lightbox controls should automatically close the lightbox panel.
The lightbox in the earlier example also had the facility to close itself when the Escape key was pressed. This is useful functionality, but how will users know about it?
Keep your users informed
There’s no point in having lightbox functionality on a site if users don’t know it’s there or conversely if it’s likely to get triggered by mistake.
So warn people about what’s going to happen if they click on or press the enter key whilst on a link. This warning needs to be in different forms to cater for the needs and abilities of a user audience.
The simplest method could be a text link that states something like “View full size version of my photo of the moon”. However, often a thumbnail version of an image is itself the trigger for the lightbox so that becomes a bit trickier. Including the “View full size…” text in the image’s alt attribute would work for screen reader users, including the text in the title attribute might help those using a mouse. But sighted keyboard users won’t get either of those pieces of information.
Including a note about the images opening lightboxes in plain text above the start of the thumbnails might be a solution.
Once the lightbox is open the method or methods for closing it should be clearly signposted. A ‘Close’ button or link would be the absolute minimum here and that link could be a sensible place for focus to sit when the lightbox is first opened – making sure that focus is clearly visible of course.
After the lightbox is closed
When the lightbox is closed focus should be returned to the link or button that caused the lightbox to open in the first place.
This improves usability and the user’s orientation within the page.
This might be a link directly to the larger version of an image, or alternatively complete removal of the lightbox functionality.
Where a lightbox panel contains form elements or other content consideration should be given to placing that content in another page otherwise key functionality may not be available to your users.
I’ve tried to crystallise the accessibility requirements down into these few bullet points:
- Links that trigger lightbox:
- Must be able to get and show keyboard focus
- Must announce that they open an image in a lightbox – for screen readers and for sighted keyboard users
- When lightbox opens, focus must be placed somewhere sensible within the lightbox – suggest a Close link above or below picture.
- Wherever focus is within the lightbox it must be visible.
- The large image within the lightbox should have appropriate alt text added – especially if it is also a link to close the lightbox.
- Either of these:
- Tabbing beyond the last link in the lightbox or shift-tabbing before the first link should close the lightbox
- Tabbing should cycle within the actionable links within the lightbox until user clicks a close link.
- Whenever lightbox is closed, focus should be returned to whatever link/or image opened it in the first place
If you feel that I’ve missed anything I’d be very grateful if you’d let me know using the comments box below. Also if you disagree with any of the points I’ve made please tell me why.
Some other accessibility posts
- WordPress Permanently Visible Log Out Link Plugin – Version 0.1 - Feb 15th, 2013
- Why None of the External Links on this Website Open in a New Window - Dec 4th, 2012
- WordPress 3.5 Accessibility Update – November 2012 - Nov 19th, 2012
- Work starting on WordPress 3.5 – Now is the time to raise those accessibility tickets. - Jul 19th, 2012
- WordPress and Web Accessibility: Why It’s Important – WordCamp UK 2012 - Jul 17th, 2012
6 Responses to “Specification for an Accessible Lightbox”
Like to leave a comment?
Please note: All comments are moderated before they will appear on this site.
Next post: ‘Fix The Web’ In Struggle For Survival