When placing audio and video elements on a web page I’ve worked on a number of pieces of work where, for one reason or another, clients want to have their media Autoplay. To us nerds it may seem like common sense that Automatically playing media to a visitor is a bad idea for accessibility. The W3C has made this clear with it’s WCAG guidelines – we’re nerds; we care about these kinds of things. It’s worth mentioning that as with most accessibility features though, proper use of Autoplay also does a lot for usability and visitor sanity for the rest of your audience as well.

In the last 6 months I’ve had a number of projects that have potentially involved autoplaying video or audio to visitors. Some of these pieces of work have been full blown interactive arty web sites where the target audience is expecting it (similar to The Wilderness Down Town), while others have simply been over excited clients or creative/designer folk wanting to make “something epic on the interweb”.

Autoplay is not a new thing, however like a lot of things that aren’t necessarily “the right thing to do” on the web, there are still a number of brands and companies doing it that should really know better.

“Crap!… mute, mute mute!”

If you’ve ever been rocking out to some tunes and visited a site that autoplays some media content with the volume on full you’ll know first hand how annoying this can be.

If this happens at work and that video you’ve just clicked on of an Asian German man techno yodelling with chickens just autoplayed, you might find yourself attracting the wrong kind of attention to your work browsing habits – YouTube makes this very clear by getting this wrong; they autoplay. My work colleagues have been wondering ever since…

Picture this same scenario but instead put yourself in the shoes of a blind website visitor – if a website is playing a video using a flash video player and a visitor viewing the site is using a screen reader, the flash video player becomes for all intents and purposes “invisible”. That pause button the website’s flash developer has placed on the page to stop the video also becomes “invisible” – so if you autoplay video, they may potentially be unable to stop the video playing at all.

Now if only the developers working on The Sydney Morning Herald understood this!

People who do this stuff for a living – the W3C

When it comes to building websites for a client that mandates accessibility such as the Government or a major corporation the main source of reference that everyone turns too is the W3C and their Web Content accessibility guidelines (WCAG 2.0).

In the section of the specification talking about implementing audio, there is a quote that is definitely worth a read (Understanding Success Criterion 1.4.2 [Audio Control]) (source)

“…
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.
…”

If you are implementing anything that allows for visitors to Pause, Stop and Hide multimedia they also mention the following (source):

“…
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.
…”

The future of media on the web – HTML5 Audio/Video

The current work-in-progress HTML5 specification from the W3C includes new attributes that support autoplaying media with the autoplay attribute of video and audio elements with the following statements appearing inside the “HTML living standard”:

“…
Authors are urged to use the autoplay attribute rather than using script to trigger automatic playback, as this allows the user to override the automatic playback when it is not desired, e.g. when using a screen reader.
…”

Many agree that having this option included in the specification is a good thing as Simon Pieters points out:

“…
Removing the attribute will not make pages stop autoplaying video. Instead they will use script to make videos autoplay, and then it becomes harder for the user to prevent videos from autoplaying. (You could have a pref in the UA to disable autoplay.)…”

A word on walled Gardens

Whether you love or hate the impact that Apple mobile handsets have had on the market, you’ve got to give it them that sometimes their opinionated take on how they implement or not implement certain functionality sometimes is spot on.

Emma Sax mentions in her post that Apple has made the decision to disable autoplay on iOS devices, both using script blocking techniques and removal of support for the attribute implementation (source):

“…
In Safari on iOS (for all devices, including iPad), where the user may be on a cellular network and be charged per data unit, preload and autoplay are disabled. No data is loaded until the user initiates it.
…

This plays the movie: <input type="button" value="Play" onClick="document.myMovie.play()">

This does nothing on iOS: <body onLoad="document.myMovie.play()">
…”

They also mention in the same document

“…
It is especially important to provide user controls on iPad because autoplay is disabled to prevent unsolicited cellular download.
…”

From recent tests we’ve done for clients on a number of current Android devices (Galaxy S3, HTC Desire) it appears that many mobile devices appear to ignore the autoplay attribute all together. Based on this I'd hesitate to even consider the autoplay attribute “usable” in a commercial development sense based on the ever growing amount of mobile traffic from visitors.

Advice if you have to “go there”

If you are working on a site that has a really strong need (subjective, or actual) to include Autoplay there are a few things you can do to make your site less painful for your visitor;

• Autoplaying your media is a lot more acceptable if your intent to play media was made before a visitor came to your page i.e. following a link that says “Click here to view this video”.
• If you ignore all I've mentioned in this post and use autoplay, ensure that your clip only lasts a few seconds to ensure that you are also abiding by the W3C spec when it mentions how you should build ‘Moving, blinking, scrolling’ content.
• If using video, autoplay with the volume muted, and give users the option of “unmuting” your media. This will stop non-vision impaired users from being embarrassed while ensuring the vision impaired can still navigate your site.
• If the clip lasts more than a few seconds, make sure that you include an extremely visible, easy to find way for your visitors to pause or stop your media. This needs to be done using semantic HTML mark-up – not just a larger “invisible” button in your flash video player.

Stop! Thief!

The motivation for this post was like many things in my life inspired by frustrations I had experienced during my work day. Like others may have done when arguing a point with others that weren’t close to the subject, I searched for reference material to back up my argument at the time as to why we “shouldn’t use Autoplay”. One of these places of reference was  Emma Sax’s post on exactly the same topic. Recently I was contacted by Emma Sax on twitter about the lack of reference I had made to her post on Autoplay and her feelings that I had plagiarised some of her writings. When I wrote this post I was lazy in that a number of her quotes from the W3C as well as Apples SDK were copy-paste jobs. This was unprofessional and crude on my part but was not meant to cause harm.

I have since rewritten a large part of this post to further separate her opinions from mine and apologised to Emma. We both share similar feelings on two things: Autoplay being bad for the internet; and due credit being given where it’s due. Emma’s post is definitely worthy of credit.