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.