Add disablekb parameter to the Youtube embed url for accessibility

I'd be interested to know the source that recommends disabling keyboard control for Youtube embed's? With this patch its possible to start video, but not to stop when using only keyboard.

@sokru, Youtube's video player offers keyboard shortcuts for certain actions (for example m for mute). These keyboard shortcuts can interfere with screenreader shortcuts, for example.
WCAG only allow one-key shortcuts when there is an option to disable those shortcuts.

This is based on WCAG 2.1.4 specification, see https://www.w3.org/TR/WCAG21/#character-key-shortcuts

The solution is to disable keyboard shortcuts by changing YouTube's default disablekb=0 to disablekb=1

If the parameter disablekb=1 how will the player comply with WCAG SC 2.1.1?

From the description I read that "Setting the parameter's value to 1 causes the player to not respond to keyboard controls." which sounds like a direct violation of 2.1.1. How is the player operable by a non-screen reader user with keyboard only if the player's keyboard setting is disabled?

Is the keyboard enabled behaviour in conflict with 2.1.4 by activating the keyboard commands without the player having focus ("Active only on focus" allows single key shortcuts in WCAG)?

After a second check and according to the WCAG 2.2 - SC 2.1.4: Character Key Shortcuts (Level A) guideline: Letter, punctuation, number, or symbol characters keyboard shortcuts are allowed if at least one of the following is true:

• A mechanism is available to turn the shortcuts off;
• A mechanism is available to remap the shortcuts...;
• Keyboard shortcuts are only active when that component has focus.

That means we have no issue with YouTube videos, since one-key shortcuts are only active when that video has focus.

I'm reopening this ticket because I just got feedback from 2 independent accessibility teams regarding youtube embed video player.

It all comes down to the interpretation of "User Interface Component" - on my comment 6 I was interpreting it as "the embedded Youtube video and its control buttons" but that is an incorrect interpretation in the context of what this module does, which is embedding a youtube player on a web page.

At the bottom of the WCAG "understanding" page, it is defined as:
"a part of the content that is perceived by users as a single control for a distinct function"

So a "play" button is a user interface component, but an "embedded youtube video" in its entirety isn't.
Which means that it is considered a violation of EN 301 549 / WCAG and needs to be fixed.

In other words, the "M" for "Mute", "F" for "Full screen" or "K" for "Play/Pause" might only work if the keyboard focus is on the control button itself. Nowhere else.
That's why we need "disabekb=1" to make it accessible.

Based on my tests (Chrome on Mac OSX) adding "disablekb=1" would partially break WCAG SC 2.1.1 resulting in violating also WCAG SC 1.2.2 for keyboard users by making it impossible for the user to choose captions.

According to Bureau of Internet Accessibility the Youtube player should be accessible in regard to keyboard use (https://www.boia.org/blog/are-embedded-youtube-videos-bad-for-accessibility). This was also the understanding on the Drupal accessibility channel earlier.

How did the two accessibility teams solve the issue of managing captions on keyboard if "disablekb" is on?

@simohell, I'm not sure if I fully understand your point about captions because they are selectable just using the keyboard.
In fact, if you "Tab" through, you can select every single option/control on a youtube player so with a combination of "Tab"+"Enter" we are sure that the player keyboard navigation is compliant with WCAG2.1.

The youtube player, by itself, is accessible but the problem lies in the interpretation of "User interface component" concept, as I tried to explain in my comment 7. A youtube player, when embedded on a web page, is not a user interface component according to the definition provided at "Key Terms" > https://www.w3.org/WAI/WCAG22/Understanding/character-key-shortcuts.html

Another approach to this issue would involve creating a button to add the "disablekb=1" to youtube embed iframe, to make it optional, but this would need an extra element on the page (a button or so).
Using "disablekb=1" on a youtube embedded video, seems to be the best way to make your webpage fully accessible and it's necessary for users using a screen reader.

I'm marking this as rtbc because the output generated by the patch was approved by the 2 independent accessibility teams we're working with.

Please attach the reviews you have, as they contradict the short discussion (not a formal review) at Drupal's Accessibility teams #accessibility channel on April 4 this year. The understanding there was, that the Youtube player is not in breach of SC 2.1.4 with the default keyboard option.

For clarification could you give an example of a real use case where the players default keyboard controls cause accessibility problems? It would very much help to understand the propose solution.

I have retested Youtube player for keyboard accessibility with disablekb=1 setting on.

Please see the linked video recording on how Youtube Player with disablekb=1 setting breaks keyboard navigation on the subtitles, translation and quality settings. First part of the video has default keyboard behaviour and the second part has disablekb setting on and some of the settings are totally inaccessible to a keyboard user.

https://youtu.be/rfXD7bXQRQg

I did not actually test with a Drupal installation but it uses the Youtube player, right?

I have now tested this on Drupal 10.3.x (with Umami-demo) adding a video embed field to the article content type. I embed a Youtube video with English subtitle to a piece of content.

With unpatched 2.x branch:
I navigate to a video by keyboard
I set the subtitles on
I set the subtitles auto-translation on to German
I see German subtitles

WIth patch applied
I navigate to a video by keyboard
I set the subtitles on
I navigate to subtitles configuration option
I am blocked from accessing the settings

This patch therefor breaks modules existing support for WCAG SC 2.1.1.

Unfortunately, this makes the original violation no less real and it appears to mean that youtube-embeds cannot at this time be implemented in a straightforward manner while retaining WCAG compliance.

I've reported this to Youtube as a bug since this behaviour is not mentioned in the documentation regarding the disablekb function - https://developers.google.com/youtube/player_parameters

It seems that, rather than disabling arrow keys & such only for the standard player behaviours where they are considered "Single key character shortcuts", they just globally disabled the use of arrow keys & such within the embedded player, which then breaks the other WCAG rules.

In comment #7 it was said, that this issue is a definition issue (It all comes down to the interpretation of "User Interface Component" ), while accessibility is for people actually using it. I would like to get an actual user story about when the proposed change increases accessibility instead of reducing it. Making Drupal harder to use for people for keyboard only users just to check a box in a form does not seem right, if there is no actual accessibility benefit.

It seems to be incorrectly stated in #9 that disabling keyboard support would be required for screen reader support. VoiceOver I think has no issues with Youtube while JAWS, NVDA and Narrator have built in commands to start using the player with keyboard shortcuts active. With the screen reader in such mode active should not result in any keyboard conflicts.

WCAG does however state that with voice input there may be issues with single letter commands due to background noise. Not sure how to tackle this.

(I guess the best person to get a comprehensive answer to this would be Rain who is all of Drupal Accessibility Maintainer, Google Staff UX Design Manager and W3C Accessibility Guidelines Working Group Member)