Autoplay is bad for all users

Autoplay is a bad idea not just for accessibility but for usability and general sanity while browsing. This article will explain what the problems are, where to find backup for arguments and what you can do if autoplay is a must have.

Autoplay of embedded audio and video clips is often requested from clients for a number of reasons, one is to increase view/listen stats when an advert is preceding it and fewer views can mean less revenue.

Interruption to browsing

When arguing a case to prevent autoplay from being used it is probably easiest to start with the following; the sound from the clip will override or conflict with other sounds that any user is listening to at that time.

At best, this is intrusive for someone who is listening to music or in a quiet area while browsing.

At worst, the site becomes unusable for people who have to listen to their screen-reader software and can not continue browsing the page until the clip has finished (if it ever does – think of a looping background sound on a page).

To understand the frustration that screen-reader users face, think of the interruption caused by advertising overlays that obstruct what you are trying to read where you can only continue once you’ve found and clicked on the close button. Except that the overlay is covering the entire page, has a transparent background so words are overlapping each other, and the close button only appears once you’ve read the overlay’s text!

W3C says autoplay is bad

The more referential, perhaps more respected, examples come from the W3C’s specification for accessibility (WCAG 2.0).

There is a small note in one of the audio criterion, that really should be applied to all multimedia:

Note: Playing audio automatically when landing on a page may affect a screen reader user’s ability to find the mechanism to stop it because they navigate by listening and automatically started sounds might interfere with that navigation. Therefore, we discourage the practice of automatically starting sounds (especially if they last more than 3 seconds), and encourage that the sound be started by an action initiated by the user after they reach the page, rather than requiring that the sound be stopped by an action of the user after they land on the page.

‘Understanding Success Criterion 1.4.2 [Audio Control]‘

Another piece of information can be found in the ‘Pause, Stop, Hide’ criterion, which says:

Moving content can also be a severe distraction for some people. Certain groups, particularly those with attention deficit disorders, find blinking content distracting, making it difficult for them to concentrate on other parts of the Web page. Five seconds¹ was chosen because it is long enough to get a user’s attention, but not so long that a user cannot wait out the distraction if necessary to use the page.

‘Understanding Success Criterion 2.2.2 [Pause, Stop, Hide]‘

Autoplay advice

If the business case for autoplay is too strong to counter there are ways you can mitigate it’s use.

1. Only autoplay if the clip lasts for five seconds or less
2. If the clip lasts over five seconds, you must provide the user with the option to stop or pause it
3. Autoplay is generally acceptable if the user was aware, when they clicked the link, that the proceeding page was going to play a clip

Footnote

1. ‘Five seconds’ relates to the timing mentioned in the success criterion for ‘Moving, blinking, scrolling’

Posted in: Web standards and accessibility

April 28, 2009