Under WCAG 2.0, anything that moves on its own for over five seconds beside other content must let visitors pause, stop or hide it. Slow the slides, add a visible pause button, or stop them moving by themselves.

Gone before the last line

A slideshow fills the top of the home page. Each slide has a headline, a sentence of detail and a button, and every four seconds it moves on.

The owner reads every slide with ease, having written them. A visitor reading at their own pace reaches the middle of the sentence, and the slide is gone.

It comes back, eventually, after the whole cycle. By then most visitors have given up on it, and some of them needed what it said.

Who cannot finish a slide

The third is the one owners rarely picture. Someone using magnification moves around a slide in pieces, and by the time they reach the button, the slide holding it has gone.

What the standard asks

WCAG 2.0, the accessibility guidelines most organisations measure against, covers this in success criterion 2.2.2, Pause, Stop, Hide.

Three conditions bring content under it: the movement starts automatically, it goes on for longer than five seconds, and it shares the page with other content. When all three apply, visitors must be offered a pause, stop or hide control.

A slideshow that cycles on its own meets all three conditions. The criterion is at level A, the most basic, so a site aiming for the usual AA level has to meet it too.

Slower is better, but not enough

Slowing the slides helps. A slide with an event's date, time and price needs far longer than a photograph with two words on it.

But no single speed suits everyone, and slower movement still moves. The criterion asks for control, not a better guess at reading speed.

Pausing while the pointer rests on the slideshow, or while a keyboard user has tabbed into it, helps too. Phones have no pointer to rest, though, so a visible control is still needed.

A pause button people can find

Put it where it can be seen at all times, not only when the pointer is over the slideshow. Label it in words, or give it a text label a screen reader announces, such as pause slideshow.

Make it reachable with the Tab key and large enough to tap with a thumb. Once pressed, it should stay paused until the visitor restarts it, not resume after a few seconds.

The arrows and dots need the same care. Dots a few pixels wide are hard to hit and say nothing to a screen reader unless each is labelled.

A worked example

A music venue with a bar and a few hundred capacity had a home page slideshow of upcoming shows. Each slide carried the act, the date, door time, the age restriction, the price and a ticket button.

The slides changed every four seconds. Regulars said they could never read the date before it went, and the box office took calls asking which night a band was playing.

On phones, a slide sometimes changed just as a thumb reached the ticket button, so the tap opened the next show's ticket page. A few people bought tickets for the wrong night.

The mechanism was a moving target in both senses: text that left before it was read, and a button that changed under a finger.

The rebuilt page lists the next shows as plain text, date first, with the rest of the month below. The slideshow survives on the gallery page, where it moves only when a visitor swipes or taps a labelled arrow.

Or let the visitor move it

The other answer is to stop the automatic movement altogether. Show the first slide, and let visitors move to the next with clearly labelled arrows when they choose.

Better still, ask whether the content needs to be a slideshow at all. Five upcoming events, five services or five offers usually read better as a list, all visible at once.

A list works on any screen, needs no controls and hides nothing behind a wait.

Movement pulls at the eye

The criterion covers content alongside other content for a reason. Motion at the top of a page draws the eye away from the text a visitor is trying to read further down.

For people with attention difficulties, that pull can make the rest of the page hard to read at all. Stopping the slideshow helps them even if they never look at it.

What a screen reader hears

Screen readers read a page in order. A slideshow that changes while one is reading can move the listener's place, or announce new text in the middle of something else.

Some slideshows hide every slide but the current one from screen readers, so the other messages never exist for those visitors. Others read out all of them in a row. Neither is what the owner intended.

Checking your own slideshow

Read one slide aloud at a slow, steady pace and time it. If the slide moves on before you finish, it is too fast for many visitors.

Then try to pause it using only the keyboard, and again on a phone. If either fails, so does the slideshow.

Switch on your phone's own screen reader for a minute and listen to what the slideshow announces. It is usually less than the owner expects.

The counter-case

Not all movement is a problem. An animation that plays once and stops within five seconds is outside the criterion, and so is a gallery that moves only when the visitor asks.

A slideshow of photographs with no text matters less for reading, though it still distracts and still needs a pause control if it cycles on its own.

But anything a visitor must read to act deserves to stay still. Slow it, give it a pause button, or stop it moving by itself.

The check

  1. Read one slide aloud at a slow pace.
  2. Compare that time with the slide timing.
  3. Find the pause control using only the keyboard.
  4. Pause it on a phone and wait a minute.
  5. Label every control in words.
  6. Move dates and prices into plain text.
  7. Turn off automatic movement if nothing else works.

Step six matters most for a business whose slides carry facts. A date, a price or a deadline that a visitor needs in order to act belongs where it stays put.

Another everyday barrier with a quick fix is covered in required fields marked only with a star.


Frequently asked questions

Why are fast slideshows an accessibility problem?

Slow readers, screen magnifier users, people reading in a second language and anyone interrupted cannot finish a slide before it changes, and what they needed disappears.

What does WCAG 2.0 require for slideshows?

Under success criterion 2.2.2, anything moving by itself for longer than five seconds, next to other content, must give visitors a way to pause it, stop it or hide it.

Is slowing the slideshow enough?

It helps but does not meet the requirement on its own. Visitors still need a pause control, and slides carrying dates or prices need far longer than a photo.

What makes a good pause button?

One that is always visible, labelled in words, reachable by keyboard, large enough to tap, and that keeps the slideshow paused until the visitor restarts it.

Does pausing on hover work?

Partly. It helps mouse users, but phones have no hover and keyboard users need focus to pause it as well. A visible button covers everyone.

Should the slideshow go altogether?

Often, when it carries facts people need. A plain list of dates, prices or offers stays put, reads on any screen and needs no controls.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Slides changing before visitors finish?

Send us your home page. We will time each slide and check whether its controls work by keyboard and touch.

Start a Conversation