The Unbearable Inaccessibility of Slideshows

Originally published at:

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 ( was built with Bootstrap (with some heavy modifications). AccessibilityOz ( 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:

  1. Allow the user to stop all movement
  2. Provide visible controls accessible to the keyboard, mouse and touch
  3. Provide a valid and understandable focus order through the slideshow
  4. Valid coding and style sheets
  5. 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

You have no idea how happy it makes me - from a purely selfish viewpoint - to see these two requirements spelt out like this. So many sites have slideshows, and so few have any way to pause them, that I habitually keep JavaScript disabled as a form of self-defence. Where there is a pause mechanism, it tends to be on mouseover. (I can use a mouse, but keyboarding is generally much easier.)

Thank you for raising awareness of this, and I look forward to your next article.


I think this may be the first time in awhile that my knee jerk reaction to an article (in this case, “Yeah, yeah, another whining piece about modern and/or current UI practices”) has, after reading through the article, been rescinded. Very good points are made here, some of which I’d never really stopped to consider, and as both an Internet user and a developer, I’ll definitely be keeping this in mind, especially in current and future projects. Thanks!


Great and much needed article. I think we should be careful about suggesting alternative formats. Other alternatives would be to rethink your approach and implementation. I think there are rare cases where you would need to provide an alternative format and when one is required, rethink your design.

Question about the implementation. I noticed a role=“listbox” but no children had role=“option”. Was this intentional? Or, maybe I’m missing something. If you could speak to the “role” ARIA plays with carousel accessibility that would be fantastic.

To be honest leaving role=“listbox” in there was an oversight: we were trying a few things out and that got left in accidentally.

Thanks for spotting it!

Very useful article Gian. I’ve been contemplating building an accessible carousel for a while so I’m really looking forward to part 2 of the article.

I’ve been doing a lot of work with jQuery and ARIA over the last few months, and it occurs to me that in some ways a carousel resembles a tab panel setup. The coloured blobs could work like the tab headers with suitable labelling. I’m wondering if your solution will go down that route.

I have to code the damn things all the time anyway since clients love them, but I personally loathe them.


Thank you for this article. I too have struggled with the lack of appropriate, accessible slideshow plugins and/or code to accomplish this feature. But let me throw a wrench into the works…Is there a way to construct a slideshow feature that is considered as decorative and completely ignored by AT? Is there the equivalent of ALT=“” for the slideshow?

My rationale is that 99% of the time these slideshows are simply decorative visual elements that do not contribute to the content of the page - or - they are a feature of what is essentially a gallery page which to some visitors is not perceivable.

Thanks again.


We’re still thinking about how we want to handle the position indicators, but yes, that does sound like a pretty reasonable way to approach it.

This is something we’ve thought about. Stay posted for the next article!

1 Like

If you have to build those, at least use the proper styling:
</shameless plug>

Great article. Slideshows become a real pain in the rear on mobile devices no matter how carefully they’re designed. I try to avoid using slideshows as much as possible.

Thanks for this article Gian. I wish I’d seen it earlier! I am definitely going to distribute the link to our developers and project managers. Maybe they can convince our clients to avoid them.