Originally published at: http://www.sitepoint.com/unbearable-accessible-slideshow/
Slideshow. Slider. Carousel. Whatever you call them, they’re ubiquitous on organizational home pages across the web. And almost all of them are inaccessible.
Sometimes they are inaccessible because people just don’t care about accessibility. But in most cases there are just so many accessibility requirements that need to be addressed that a couple of them get missed. And that can be disastrous for accessibility.
Unfortunately none of the mainstream toolkits like Bootstrap, Foundation or Slick Carousel get the accessibility right by default, so if you want an accessible slideshow, you need to make substantial changes.
In this article, we are going to look at all the accessibility requirements that need to be addressed to create an accessible slideshow. In the next article, we’ll be providing guidance and actual code to make an accessible slideshow.
There are two main types of slideshows that we often see. The first one (Figure 1) has circles to indicate the slides and provides a method of moving between slides. The second one (Figure 2) has arrows at the left and right edge of the slideshow to allow users to choose the next or previous slide.
Figure 1 Figure 2
The biggest problem with these slideshows is that they cannot be paused by the user. The next most serious problem is that neither is keyboard accessible. In the first example the keyboard skips the slideshow entirely.
In the second example the arrows are not keyboard accessible, but the link within the two slides in the slideshow is. This means that the keyboard focus disappears when it is focused on a slide not currently visible.
We have released two slideshows recently. Energy Rating (www.energyrating.gov.au) was built with Bootstrap (with some heavy modifications). AccessibilityOz ( www.accessibilityoz.com.au) has an accessible slideshow that was also based on Bootstrap (with even heavier modifications).
There are five principles that need to be met to create an accessible slideshow:
- Allow the user to stop all movement
- Provide visible controls accessible to the keyboard, mouse and touch
- Provide a valid and understandable focus order through the slideshow
- Valid coding and style sheets
- Provide a meaningful alternative to the slideshow
Principle 1: Allow the user to stop all movement
One of the reasons marketing departments like slideshows is because there’s movement on the page, which draws the viewer’s attention to that area.
Allowing users to control the movement of a slideshow is one of the four “non-interference” clauses in WCAG2. These four success criteria apply to all content on the page – even content that is classified as inaccessible by the owner.
The specific success criterion is 2.2.2: Pause, Stop Hide : For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential.
And I don’t think anyone can argue that a slideshow is essential!
As WCAG2 says, “the intent of this Success Criterion is to avoid distracting users during their interaction with a Web page”. It is not sufficient to pause the movement when it receives focus. It must be able to be completely stopped by the user, via the keyboard, mouse or touch (on a mobile device).
The easiest solution is to provide a link that stops the movement. We’ll talk more about the best way to implement this in the Controls section under Principle 2.
One more thing on movement: if you can at all avoid using an animated slide or fade in/out effect then do so. Transition effects are one of the biggest accessibility issues in a slideshow as both slides must exist in the DOM at the same time. If you can avoid transitions then your slideshow will be much easier to make accessible.
Principle 2: Provide visible controls accessible to the keyboard, mouse and touch
Far too often the controls on a slideshow are very small, or quite low-contrast compared to the content they overlay. And focus / hover is often not too obvious either. There are four requirements to think about here:
- A. Are there controls to stop, start and move between slides?
- B. Are the controls highly visible (large enough to be seen and meet colour contrast requirements)?
- C. Is the focus/hover indication sufficiently different to the default state while also having enough contrast with the content?
- D. Can the controls be manipulated by the mouse, the keyboard and touch?
A. Are there controls to stop, start and move between slides?
As mentioned in Principle 1, it is absolutely essential that users be able to stop all movement in the slideshow, via the mouse, the keyboard or touch alone. Also necessary is the ability for users to restart a slideshow if they have stopped it. It is not an actual requirement that users be able to move between slides, but it’s a good idea.
B. Are the controls highly visible (large enough to be seen and meet colour contrast requirements)?
We see problems with this requirement on a lot of slideshows. Either the controls are teeny-tiny or the controls are overlaid on the content and colour contrast is entirely dependent on the underlying slide. There are a number of solutions to this, including having a solid background behind the control which provides the contrast, and using a solid border around the control which provides the contrast.
C. Is the focus / hover indication sufficiently different to the default state while also having enough contrast with the content?
We mostly see focus indicators only appear on mouse hover (and not keyboard focus) and often it consists of only a slight colour change of the controls. It is important that if you are going to use a colour change you need to meet colour contrast requirements.
An even better solution is to add a box around the control on focus, like we have on the AccessibilityOz slideshow (see Figure 3 and 4). But remember it needs to appear on keyboard focus too!
Continue reading this article on SitePoint