Fixed: Inaccessible YouTube Embeds

Most of us in the accessibility biz (do we call it that? I think we call it that…) already know that YouTube’s default embed code is problematic. Specifically, the fact that the <iframe> does not have a title attribute is an automatic WCAG 2.0 AA failure.

The Existing title Issue

There has been some debate on the merit of this WCAG failure, but you would likely see it flagged as a failure nonetheless. Drupal addressed this a couple years ago, though that means a separate call to YouTube for every embed. WordPress is working to address it, perhaps in 4.9. Neither of these, however, is a panacea since users can embed YouTube into these platforms in ways that are not caught by these updates, and users can embed YouTube in all the other platforms that exist. Thankfully, there is a report open with Google in the non-bug-tracker Google Group.

For those who are not familiar with HTML but still have to stuff YouTube into pages, here is an example of the standard embed code with the title highlighted.

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/dQw4w9WgXcQ?rel=0" frameborder="0" allowfullscreen title="YouTube embedded video of Rick Astley.">&tl;/iframe>

A New <button> Issue

I found a new one this week that cannot be so easily remedied by the user when pasting the code into the page. Specifically this is about a control with no accessible name — the play button. Bear with me on the following embedded video. You do not need to play it to see the problem.

When that code is rendered, prior to playing it, there is a big button in the middle of the video placeholder that acts as the play button. Pressing this loads the video and loads the video player controls at the bottom of the video (which uses a different play button). Here is the code for the big play button:

<div class="ytp-cued-thumbnail-overlay" data-layer="4" style="">
  <div class="ytp-cued-thumbnail-overlay-image" style="background-image: url("https://i.ytimg.com/vi/dQw4w9WgXcQ/maxresdefault.jpg");"></div>
  <button class="ytp-large-play-button ytp-button">
    <svg height="100%" version="1.1" viewBox="0 0 68 48" width="100%">
      <path class="ytp-large-play-button-bg" d="m .66,37.62 c 0,0 .66,4.70 2.70,6.77 2.58,2.71 5.98,2.63 7.49,2.91 5.43,.52 23.10,.68 23.12,.68 .00,-1.3e-5 14.29,-0.02 23.81,-0.71 1.32,-0.15 4.22,-0.17 6.81,-2.89 2.03,-2.07 2.70,-6.77 2.70,-6.77 0,0 .67,-5.52 .67,-11.04 l 0,-5.17 c 0,-5.52 -0.67,-11.04 -0.67,-11.04 0,0 -0.66,-4.70 -2.70,-6.77 C 62.03,.86 59.13,.84 57.80,.69 48.28,0 34.00,0 34.00,0 33.97,0 19.69,0 10.18,.69 8.85,.84 5.95,.86 3.36,3.58 1.32,5.65 .66,10.35 .66,10.35 c 0,0 -0.55,4.50 -0.66,9.45 l 0,8.36 c .10,4.94 .66,9.45 .66,9.45 z" fill="#1f1f1e" fill-opacity="0.81"></path>
      <path d="m 26.96,13.67 18.37,9.62 -18.37,9.55 -0.00,-19.17 z" fill="#fff"></path>
      <path d="M 45.02,23.46 45.32,23.28 26.96,13.67 43.32,24.34 45.02,23.46 z" fill="#ccc"></path>
    </svg>
  </button>
</div>

Neither the <button>, its nested SVG, nor its parent <div> has an accessible name. There is no plain text equivalent to what we are seeing on the screen.

Screen Reader Demo

So what does it mean to have no accessible name? A piece of assistive technology, such as a screen reader, cannot identify it to users as anything other than what element it is (in this case a <button>). A screen reader user familiar with YouTube embeds will likely already know this issue and may have already worked around it and forgotten that it is a problem. That does not make it ok, though.

The source for the example videos is a CodePen I made to test the issue (and ask for input on the Twitters). To spare you the hassle of having to listen to them, here is what each of my two examples says:

NVDA / Firefox:

Button

JAWS / IE11:

Unlabeled one button

Don’t Confuse This One

If you dig around the code and look for an aria-label (after exhausting all the other ways to provide an accessible name) you may find this play button, but it only appears after the video has started playing and does not help a user trying to start a video:

<button class="ytp-play-button ytp-button" aria-label="Play">
  <svg height="100%" version="1.1" viewBox="0 0 36 36" width="100%">
    <use class="ytp-svg-shadow" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#ytp-id-11"></use>
    <path class="ytp-svg-fill" d="M 12,26 18.5,22 18.5,14 12,10 z M 18.5,22 25,18 25,18 18.5,14 z" id="ytp-id-11"></path>
  </svg>
</button>

In short, that just tells me that the developers at YouTube know how to address this already, they just missed the big button.

A Blog Post Is Not a Bug Report

I am writing this post at the same time I write the report. I figured if I was going to report it I might as well flag it as an issue for others to be aware of today. You can see it in the Accessible Google Group (per instructions from the Google Accessibility Twitter account). The group is moderated, so it went live a day after this post.

A Workaround?

Normally I like to be able to offer a fix. Sadly, as this code is rendered after the calling page, there is no way to just drop an accessible name into it (as with the title workaround above). I plan to write a script to parse the <button> and add an aria-label (easiest option) and when I do I will drop it here. I have just run out of time this weekend (Game of Thrones is on later and I still have to pack for GenCon).

Update: September 5, 2017

I was checking a page today that has a YouTube embed and was surprised to hear the play button get announced. I popped into the code and found this for the play button:

<button class="ytp-large-play-button ytp-button ytp-red2" aria-label="Play" style="background: rgba(0, 0, 0, 0) url(&quot;https://s.ytimg.com/yts/img/large_play_button_ringo-vfljWXIdx.png&quot;) no-repeat scroll center center / 100% auto;"></button>

I highlighted the new aria-label attribute. So perhaps this is fixed? Or perhaps there is some A/B testing going on. I have asked as a follow-up to my bug report and will update here when I have some confirmation. So far I have one confirmation on Twitter that this is not limited to me, but I am happy to hear from others.

Note that the SVG for the red box / white arrow of the play button is now a PNG. While it is unfair to call that a regression, it does make me wonder if this is old code coming up (perhaps as a short-term fix?).

Update: September 7, 2017

I have received confirmation that the play button issue I reported has been resolved:

Unfortunately I don’t have a public tracker to provide for you, however, as you mentioned this has been fixed with the new UI recently pushed.

Cool.