submitting pattern for a video element background #279

merged 1 commit into from Feb 26, 2015


None yet
5 participants

mpiotrowicz commented Jun 10, 2014

not a super wide use case but could be useful nonetheless


svinkle commented Jun 10, 2014

I'll be implementing it shortly. :-)

mprins commented Jun 13, 2014

having moving/animated content on a page without any means to control it can mean a WCAG level A failure. see:


mpiotrowicz commented Jun 13, 2014

Yeah, I feel like these types of video backgrounds are a bit of a grey area. Having movement on a page without explicit ability to control it isn't ideal, but this pattern is definitely growing in popularity from a design standpoint so just thinking of any way to make this a little friendlier.
The way I've understood these guidelines, limits are to prevent users from missing content within the sections that are animating. Strictly speaking, there isn't content that's rotating within the videos, so I'm not 100% they apply in this case?


svinkle commented Jun 13, 2014

Perhaps to satisfy the requirement of controls, you could place them before the video element (tab order) as .visuallyhidden.focusable. This way the controls are on the screen but are visually hidden in order to meet design requirements.

mprins commented Jun 15, 2014

@svinkle hiding the controls makes them unavailable (or at least very hard to find) to touch/pointer interfaces which stll makes it impossible to stop/start

mprins commented Jun 15, 2014

By adding the aria-label it is clear that this thing is information and not decoration (if it were decoration it should get aria-hidden so it can be ignored by AT)

Also this with kind of thing guaranteeing contrast between background and foreground can be really hard.


mpiotrowicz commented Jun 15, 2014

adding to discussion on controls, they'd still be available to a screen reader which would be confusing for an element that has role="img".

@mprins I think much of this boils down to whether or not these videos actually provide any content. I view them really like more complex background images, an extension of the already very popular trend of "full bleed" background images like you see on Medium posts.
I think they really straddle the line between "purely decorative" where aria-hidden would work, and "convey impression or emotion" where some kind of "alt" version would be necessary.
Color contrast is definitely another concern, as it is with the static image version I linked to. Despite these drawbacks however, I don't see this design trend dying down, so just thinking of ways to improve on an imperfect pattern.

If this PR is only going to create confusion and ambiguity with the pattern library, am fine with closing!


svinkle commented Jun 15, 2014

@mpiotrowicz I like this point. I think it comes down to content and/or context. Thinking about background images, they're usually displayed only for decoration/presentation. I think the same could be said for background video. The content would be handled by any overlying text.

One concern at this point might be Guideline 2.3: Do not design content in a way that is known to cause seizures. I'd like to think content authors would only upload a video background with a calming or non-distracting nature, but it's never safe to assume. This is where having the controls come in, but like you said, controls on an "image" doesn't make sense.

This is a very interesting dilemma and I'd like to see this make it to the pattern lab in some form. I agree this is a new, common design treatment that will be implemented more often in the future. It would be great to tackle this now and make sure it's implemented correctly for present and future sites.


mpiotrowicz commented Jul 15, 2014

Not sure what to do here, anyone have any more feedback/ideas? Can close if this isn't helpful here. Let me know!


grayghostvisuals commented Jul 17, 2014

I wouldn't close it. Looks like y'all just need some more sorting out to do :)


grayghostvisuals commented Oct 10, 2014

@mpiotrowicz What if we add a way to pause like @emmasax mentioned recently in her article?


mpiotrowicz commented Oct 14, 2014

Yeah I commented in that article, it's probably the best solution, only question I still have is around screen reader use and that pause button. If role="image" is used, then that button is kind of confusing? Maybe role="image" isn't useful afterall...


grayghostvisuals commented Oct 14, 2014

I'll leave this issue open until we have a better conclusion to all this. Let me know if you need any help :)


grayghostvisuals commented Feb 24, 2015

Hey there @mpiotrowicz You wanna pull this in? Up to you to close or merge :)


mpiotrowicz commented Feb 26, 2015

Hooookay, I've added play/pause functionality as suggested in the above article. I've also added a caveat with a link to the article. I'm torn because overall this isn't always a great pattern for people to use so I don't want to endorse it necessarily, buuut, this is a way of implementing that pattern in a way that's much friendlier. If we get flack from anywhere, I'll happily remove


svinkle commented Feb 26, 2015

The icons should be reversed. Currently, while the video plays the 'play' icon is shown when it should be the 'pause' icon. When paused the 'play' icon should be displayed.


mpiotrowicz commented Feb 26, 2015

yikes good catch! fixed


davatron5000 commented Feb 26, 2015


mpiotrowicz added a commit that referenced this pull request Feb 26, 2015

Merge pull request #279 from mpiotrowicz/pattern/video-bg
submitting pattern for a video element  background

@mpiotrowicz mpiotrowicz merged commit 2d67c16 into a11yproject:gh-pages Feb 26, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment