Accessible HTML video as a background
TweetToday I got a comment on Autoplay is bad for all users which asked:
So why does this high-traffic site designed by a former top-Google UX designer use it?
The comment has linked to a page which has video as a background element playing underneath the introduction text and call to action button, the images are moving but there is no sound on page load. At times this apparently important information is completely invisible.
Using video as a background is on the increase so it’s important to know how to make it accessible for everyone.
What does WCAG say about it?
I don’t think there is a guideline that specifically relates to this latest design idea of putting moving video behind the introduction content. However, I think that 2.2.2 Pause, Stop, Hide is most applicable:
Moving, blinking, scrolling:
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
While the moving background isn’t specifically ‘information’ it is interfering with the information presented alongside it, it starts automatically and lasts more than five seconds. So in this case you should provide the user some way to pause it.
On whether we should autoplay video on page load, generally I would say no. However in this implementation it is almost never accompanied with sound and that is usually the biggest annoyance for people trying to use a site – so I think we can have a little leniency on autoplaying background videos.
HTML video backgrounds in the wild
airbnb
- Bad: no pause button
- Bad: no blurring – hard to read content sometimes
- Good: slow moving video
- Good: fixed camera view
Canva (mentioned by the commenter)
- Bad: no pause button
- Bad: no blurring and white text – content invisible at times
- Bad: fast moving video – very distracting
- Bad: very wobbly camera view
Spotify (a landing page)
- Bad: no pause button
- Bad: hammock scene could cause motion sickness
- Bad: white text – not always legible
- Good: large blocks of colour in the video
Sportswood Printing
- Bad: no pause button
- Bad: panning scenes could cause motion sickness
- Good: darker video with light text relatively easy to read
Powerhouse Company
- Bad: no pause button
- Bad: panning scenes could cause motion sickness
- Bad: white text – not always legible
- Good: slow moving video with large blocks of colour
I think you get the idea.
How to do it right
PayPal‘s video background is an excellent example of how to handle the implementation in an accessible way without compromising the design:
- There is a pause button in the bottom right of the video
- The text is readable when any colour appears underneath
- The video is relatively dark with lighter text on top
- The video has large blocks of colour which are slightly blurred
- The video has a static frame, movement only occurs inside that
- The video has an end, it is not looped
- Once the video has ended, the background fades slightly darker to make the content more legible
I’m not immune to making a mistake, a couple of sites I’ve built recently don’t adhere to the principles I’ve outlined above. But now that I’ve taken the time to look into some best practices I’ll be updating those sites in the future.
Use PayPal’s example as how to do things right, don’t copy the self-proclaimed top designers. And, do as I say not as I do!
[…] Accessible HTML video as a background […]
I couldn’t agree with you more, auto play is a questionable practice for all the reasons you state above plus in your previous post ‘Autoplay is bad for all users’ however there are a couple of additional layers to consider.
Firstly, I worked for a large broadcaster in the UK on the accessibility of their live and catch up TV service. I have been present in user testing which baked up the need to not use auto play however I have also spoken to screen reader users who have requested auto play. On sites that you use often, such as catch up TV, auto play removes the need to navigate the page to get to the media player, find the play button and hit play (that’s if the media player is accessible). Instead you choose your programme from a listing page and away you go.
For live content such as TV, live events (Olympics, music, sports etc) there is a very strong business case to require auto play – it’s there because users want to get to the content fast and not miss anything.
This doesn’t mean auto play gets a free pass however, it just means it needs to be managed.
For example an accessible popup can be presented to first time visitors asking them if they want to auto play content and then save their preferences should they want. If you have a sign in service you can also manage preferences there.
Paypal have a fairly good implementation however I’d place the Pause button higher up in the content order so you can get there faster. The key is giving the user control and quick access to that the ability to control the page.
@henny thanks for your feedback. Catch-up tv and live events are definitely one of the biggest examples of where autoplay isn’t the enemy.
@Henny If that’s your only comment on PayPal’s implementation, then that’s pretty darn good :-)
@Emma Great article, thank you!
I completely agree with Henny’s point about asking on first play and saving preferences.
It can’t go any further than that though. Take the Olympics example.. It’s not like YouTube, not every single page on the site is designed to serve video. So someone coming from Google simply clicking a link about a record win has no reason to think that it might have autoplaying video.
One idea that we discussed at that broadcaster (that wasn’t implemented sadly) was to remove autoplay by default and only autoplay videos that came from a clearly denoted ‘play video’ link by passing a parameter (eg. ?autoplay=true). That, combined with what Henny said about preferences, would to my mind be a reasonable way of handling those kind of media heavy sites.
However for everything else, my opinion is a little stronger. There is never any excuse, the best practices above just make it a bit less bad for some people, they don’t fix it.
WCAG mentions it a little with references to ADHD, but it’s as always important to remember that accessibility isn’t just about blindness, or even primarily about blindness, there are many other far more prevalent conditions to also take into account. (char limit reached)
(continued) In the case of autoplaying audio or movement, the thing to bear in mind the most is autism. The testing session that has stuck with me the most from all my time there, one, which Henny might also be familiar with, involved an autistic woman who was navigating fine, until she arrived on a page that had a simple auto-cycling promo carousel.
The sudden unexpected movement of it sliding across caused her so much distress that she turned the PC off and abandoned the session.
Most accessibility issues are about avoiding barriers to accessing information. That’s as bad as the consequences can be.. not being able to access a service, perform an action, etc.
Which is of course bad enough in itself. But that happening as a consequence of causing someone acute distress takes it to a whole new level.
So for that reason, in my opinion at least, autoplaying audio or movement is the worst accessibility mistake that someone can make.
@WebAxe Well, my other comment would be to not have background video at all ;) To be honest it’s an all round barrier and, for me at least, it feels like the new splash screen. On the plus side the Paypal implementation has it disabled for devices.
@Emma Great article on a topic that needs a good airing so thank you!
“Autoplay is generally acceptable if the user was aware, when they clicked the link, that the proceeding page was going to play a clipâ€
For me that feels like too much of a loop hole. If I click on a link that says ‘Play video’ and I expect to play video that’s fine. But if that video sits in a page that has lots of surrounding content then, as a screen reader user, I still can’t access the rest of the page. So forewarning the user only addresses part of the problem in as far as the user is told they will have a problem. If the ‘Play video’ link opens a media player in it’s own window however (with appropriate warnings) then that’s a different matter.
On the Olympics site that Ian mentioned we had a live video player which sat in it’s own page with surrounding links to live content in different channels (links which were also available within the player). We made sure that all links forewarned the user that the video would play but even then we couldn’t guarantee 100% success as external sites might also be linking to the page in question, not to mention search engines etc. We ’t convinced that a warning was sufficient so we removed auto play at the 11th hour. We wanted to put in an auto play opt in but given the hard deadline of the Olympics we didn’t have time to implement it.
My point is that even though there was an extremely strong business case to auto play the live player, backed up by some disabled users in user testing, the barrier of access out weighed the requirement for it.
@Ian It is sad that we, as developers, can cause some people such distress without knowing about it or understanding why.
My best practices were only meant to help the issues that the video background fad causes, I don’t wish it to perpetuate its use.
Businesses owners and designers see it and think it looks good and there is only so much push-back you can do without looking too negative. I know I’m not an accessibility expert, so the best way to incorporate it accessibility into real business life is to come up with some compromises to ease the pain.
I feel like everything I’m saying is excuse-making.
No, you are spot on Emma. And I love that you have written so well about it in this post and your previous post.
…plus you don’t have to be an accessibility expert to be good at accessibility :)
Thanks @Henny :)
I’ve wrestled with this myself and always have more questions than answers. I do think this trend will be around for a while given how popular it is among designers, and users to a certain extent so it’s great to see this addressed.
I do wonder though, is that video content, ‘content’? Should there be an associated “alt” text for a video used in this way, or is it just plain decoration? Probably not since I wouldn’t worry about a static version that’s a background image, but I’m not 100% sure. Here’s a quick demo of using a video with some kind of alt fallback The play/pause button as well has me a little confused – for screen reader users for example, the button is available, but will effectively do nothing. Is that acceptable?
[…] Accessible HTML video as a background […]
[…] via Accessible HTML video as a background | Punkchip. […]
Thank you very much for this, Emma; I’ve integrated your suggestions, and some of the feedback here, into my article and code for creating background video.
[…] Is autoplaying media always an accessibility no-no? muses Henny Swan, after usertesting the BBC iPlayer. […]
[…] 11. Accessible HTML video as a background […]
I’ve spent years shipping a free BBC iPlayer TV program because so many screenreader users can’t handle tabbing forty-two times to get to just the right place to press space to play the TV programme that they’ve somehow managed to get to on the confusing site.
YouTube is great in this respect, you go to a page to watch a video, and it (gasp!) plays the video. I once had a blind screenreader user very upset because a bug in one of my other products for screenreader users meant that YouTube videos had stopped autoplaying, and he found the page too confusing to use, and sharing YouTube videos was one of the main ways he engaged with his teenage sighted son.
Pages delivering video should autoplay the video.
[…] Accessibility: HTML Video as a Background […]
“Pages delivering video should autoplay the video.”
Make that “pages whose primary purpose is to deliver a single video should autoplay it” and I’ll consider agreeing with it. Even then, though, I’m working with narrow enough bandwidth that I often have to load things in the background, and I’d rather it didn’t start playing while I’m in the middle of something else.
[…] Accessible HTML video as a background [Link] […]
[…] Read my article on accessible HTML video as background […]
The layout of this site is pretty similar to my blog (which I never had time to finish…) Ok whatever…
This article is very good I like how paypal did it too! I am looking for best practices as well since I am going to implement this in a couple of sites very soon.
Great Article! It looks like paypal no longer has the autoplay video background. Would you happen to know of another website that does it right when it comes to accessibility?
I think this website does it right:
https://www.campbell.edu/
Hi, Can you suggest me that what is the best practice to implement a decorative video in accessibility and what should be the do`s and don`t for that.
[…] For more background, read Emma Sax’s article about accessible background videos […]