Replace Accessible Media Player with pure Youtube embed iframe

[kr8n3r]

What

Replaces the Accessible Media Player with a pure Youtube iframe player. This won't work on GOV.UK until the content security policy has been updated to allow youtube-nocookie.com

Why

There are a number of accessibility issues with the current video player, so other shortlisted players were prototyped and reviewed. The recommendation was to use the Youtube player with some tweaks to make it more accessible:

• Add a title attribute to the iframe, taken from the fallback link text,
• Disable option to allow single key shortcuts (disablekb) due to WCAG SC 2.1.4
• use the no-cookie version

Before (Nomensa)

After (Youtube)

Examples

• Embed video preview url
• Embed-disabled preview url

Notes

This PR also:

• rewrites the video player code so there is no dependency on jQuery or jQuery UI

Accessibility Testing of the Youtube player

Summary

Work by @selfthinker

I have implemented all 4 contending video players (Plyr, Able Player, MediaElement.js and Video.js) plus the default YouTube player and looked a bit deeper into things, especially accessibility.

There are a couple of things which all the other players inherit from YouTube. I've only tested YouTube videos with them as that is where the majority of GOV.UK videos are hosted (or maybe even 100% of them?).

Keyboard access

The YouTube video starts with an image with the generic name "photo image of" that is linked to the channel and then a hidden heading with the name of the channel that is also linked to the channel. That means if you navigate the page without a screen reader, the second tab within the iframe is always hidden. If you navigate the page with a screen reader, the first link never makes sense and the second link rarely makes sense, depending on how well the channel is named, although it always misses the information that it is the name of the channel.

It's nice that YouTube and Able Player show labels for most controls when they have focus or when you hover over them. That way it will be clearer for people with cognitive impairments. Plyr has a setting that would show them as well.

The focus ring on some of MediaElement.js's controls is quite faint.

All video players keep keyboard focus within the fullscreen view and loop to the top when you've reached the end of that screen.

Most of the players have keyboard shortcuts. YouTube uses a single key, which would be against WCAG SC 2.1.4, but that can be disabled. Plyr only uses such shortcuts when the focus is on the player, but that can also be disabled. And Able Player uses modifier keys which can also be changed, so it is never a letter just on its own.

Screen readers

I have so far tested with NVDA in Firefox and VoiceOver on iOS.
It is interesting how the various players announce that there is a video. The only way how you might know there is one with Plyr (and also the current Nomensa player) is because you will stumble upon a "play button". Not great.

YouTube is a bit better as at least you will know there is a frame (whatever might be in it). Mediaplayer.js has the words "video player" just before it and has given the player a role of "application" with the same title, and Able Player has a heading saying "media player". Much better.

All players have some kind of feedback after clicking the play button to announce that the button has changed to a pause button.

Except Plyr gives no feedback at all and even says "button play" after the button has visibly changed to a pause button. YouTube adds the letter "k" which will probably be confusing to screen reader users. On the tooltip the "k" is in brackets which makes it a bit clearer that it's the keyboard shortcut. Able Player goes a bit further and doesn't just announce what the button was changed to but also what clicking it has done to the video, i.e. "pause playing", which I find a bit confusing.

Some labels in the YouTube player are announced after the button, which is confusing. The amount of subscribers is a hidden heading, also confusing. The Plyr player often doesn't provide any feedback after activating a control, which is especially confusing when you are supposed to do something afterwards as in a dropdown menu.

MediaElement.js has half a keyboard trap. When a video has started the up and down arrows turn the volume up and down but cannot be used for the standard NVDA navigation. Tabbing still works, though.

All players show the "related videos" etc including the close button for those when pausing, but Plyr and MediaElement.js doesn't allow you to interact with them in any way, neither via clicking nor tabbing or via navigating with a screen reader. That means there is some functionality visible which cannot be accessed at all. Not good.

All players use the internal iOS video player (although that is often configurable) when used in Safari on iOS. Only Plyr doesn't do that. Plyr's fullscreen implementation still allows you to navigate the rest of the page with VoiceOver, which can be disorientating.
Voice control

I only tested with Windows Speech Recognition as I was testing when I was working from home and didn't have access to Dragon. I will re-test this with Dragon when I'm in the office.
I'm not too familiar with voice control tools, so might easily have missed something.

I could get every player to work with either "play" or "click play" or "play video" except Able Player. It wasn't working most of the time, it seems to only work with "click" when already hovering over the controls. ("Mousegrid" always works, though.)

I had trouble getting Plyr to pause. The YouTube player seemed to work best in this case.

Changing colours

None of the players are usable at all when changing colours in Firefox. Most elements are completely invisible.

Colours are not great but usable when changing colours via the Windows "high contrast" settings. Only MediaElement.js in IE11 is mostly invisible.

Captions

The only players which support switching captions on and off when they are hosted on YouTube are the YouTube player and Able Player.

Browser tests

Everything works in our supported browsers. In order for Plyr to work in IE11, we would need to implement a polyfill which I haven't bothered with for this test. So, Plyr on my playground won't work in IE11 but adding support is possible.

MediaElement.js on my playground isn't responsive. But there is a responsive setting which doesn't seem to be the default.

Conclusion

Just judging by these findings, Able Player or the YouTube player seem to be the best choice.

The question is, how much better is Able Player and in what areas that might justify choosing it over the native YouTube player? It seems to be better for screen reader users but worse for voice control users. It has support for transcripts (even interactive ones), audio descriptions (text-based or audio/video-based) and sign language (via synchronising a second video). But which of those would we actually use?
As far as I can see, both players would fail WCAG but the only proper barrier is the voice control issue with Able Player. (And invisible controls when changing colours, but all players have that issue.)

Discussion

Additionally, we'd like to add a visually hidden heading before the iframe so it's clearer to screen reader users that there is a video, e.g. "Video player".

Issue is, the heading level needs to fit into the heading hierarchy (e.g. an h2 if the heading before is an h1, an h3 if the heading before is an h2, etc, but I think we cannot programmatically establish the heading before.

Youtube Iframe API implementation

Trello Cards

• Original Trello ticket
• Change Nomensa to Youtube video player

[kevindew]

@kr8n3r woop this is an exciting change - be glad to say goodbye to the extra dependencies.

As part of your checks for whether this is good to merge could you co-ordinate with Publishing Workflow team (myself or @alex-ju are good candidates) so we can check it works in our app still. We use it to preview documents and need to re-initialise the component each preview. I ask this because it was quite delicate getting the original version to work with this. Thanks.

[kr8n3r]

@kevindew yeah will check with the team once I have it in a state that's passing test and is ready for review.

[kevindew]

Looks good to me. I'll just give it a final test run on Content Publisher before approving.

[kevindew]

Worked fine on CP 🎉

[kr8n3r]

thanks everyone for taking this on and making it solid 👍