Specification for an Accessible Lightbox
Published: | 7 Comments
Reading Time: 6 minutesLightbox 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?
Negative strips on 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
Example lightbox popup panel at Huddle Together
An example page with lightbox functionality can be found here.
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.
The tab key can get a lot of use with keyboard users
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.
A close link
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.
Javascript not available
The popup lightbox functionality is created using javascript (a scripting language which runs in browsers).
Web statistics indicate that somewhere between 3% to 6% of people browsing the web use browsers where javascript is not enabled for some reason. So it’s important that a sensible fallback is provided for these users.
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.
To summarise…
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 javascript is not present in the browser the page should behave appropriately.
Any comments?
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
- Building Accessible WordPress Themes – Featured Images - Apr 28th, 2019
- How to Build an Accessible WordPress Theme - Apr 28th, 2019
- Accessibility Checklist - Apr 7th, 2019
- Street Accessibility for the Blind in Vienna (Video) - Jul 28th, 2016
- Instagram Accessibility Reduced by New Design - May 18th, 2016
Share this page (Links open new windows/tabs)
7 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.
Previous post: WordPress and Accessibility – a11yLDNmeetup December 1st 2011
Next post: ‘Fix The Web’ In Struggle For Survival
Two points i’d like to add to the mix: touch devices, and responsive web design.
Touch devices more often than not don’t have a keyboard or a mouse. Title attributes aren’t visible either.
Add to that the smaller viewport size – numerous lightboxes i’ve seen are bigger than the width (or hight) of common handheld viewports.
Responsive web design further complicates the situation – any lightbox would need to retain its accessability throughout the various design breakpoints.
Thanks James for your useful additions. The inevitable onward march of touch devices – eg smartphones and iPads – brings new challenges to design. It is no longer safe just to assume your users are sitting at a desk.
Excellent article and topic. I really like the idea of closing the lightbox if an “outside” element is focused. A few extra mentions below:
Instead of closing the lightbox when an “outside” link is focused, what about automatically focusing the last or first focusable item (or lightbox container)?
I feel that because the user did not directly close the lightbox, it should not be closed for them. A possible solution is to add an empty focusable item at the top and bottom of the BODY and when they are focused, throw focus to lightbox. This of course solves the problem if a user goes to the browser chrome and then tries to TAB back into the page. This does not solve the problem if a user focuses a link within the page which can be done with screen readers by pulling up a list of controls and then instructing the screen reader to move to any of them. You could add listeners to each of these “outside” conrtrols and once again throw focus to the lightbox, but this could be a bit too involved for some pages.
Another problem I find with lighboxes and this pertains to mostly screen reader users, is that it can be unclear when the lightbox starts and stops when arrowning throw the lighbox content. A possible solutions is to add off-screen text to the start and end of the lightbox that would read somthing like:
Dialog Start
(content)
Dialog End
or whatever you feel appropriate.
Thoughts on user experience?
Thanks for this very usefull summary.
Another thing I also noticed in a lot of lightboxes is that the links used to navigate between pictures don’t have meaningfull linktexts. This is usually due tu a picture missing alt text or an empty link with background image serving as a button.
This is a useful specification Graham. I’d be tempted to remove the option to automatically close the lightbox when keyboard focus moves beyond it though.
From a screen reader user’s perspective it could cause confusion if the lightbox closed in this way. Imagine tabbing out of the bottom of the lightbox, then realising you needed to go back and find something.
The most likely action would be to reverse direction and shift + tab back up the page. If the lightbox had closed automatically behind you as you exited it though, the expected content wouldn’t be there to find.
It’s also possible that the scripting used to return focus to the original point on the page would be triggered if the lightbox was closed automatically in this way. Preventable, but possible, and potentially confusing if not considered by the developer.
Thanks for your comments Léonie, I appreciate that – and my thoughts have been going in that direction recently. There are some modal dialogue boxes coming through in the WordPress Admin screens for 3.6 and the point has been debated in the WordPress Accessibility forum.
So I’m guessing that you’d favour cycling the tab around the lightbox then, or would you tink it best for the focus to not move at all beyond or before the various items in the lightbox?
[…] Specification for an Accessible Lightbox […]