Is a video player considered a single component for purposes of single character shortcuts SC 2.1.4?

[mraccess77]

For the purposes of SC 2.1.4 should a video player be treated as one component where when a control in the video player is focused single characters are allowed or must it be when individual buttons are focused only where it is allowed?

Allowing the video player as a whole to be treated like a component would seem to help keyboard users rather than to have to turn off single character shortcuts and would mean that only when the video container is focused would speech users have to navigate out to dictate.

Refer to the discussion on Vimeo's github page. Today Vimeo's shortcuts work across the entire page not just within the video - but I want to be sure that the right recommendation is being given in the request for them to make a change.

https://github.com/vimeo/player.js/issues/732#issuecomment-876203730

[bskibinski]

https://github.com/vimeo/player.js/issues/732#issuecomment-876203730 Julez and other accessibility experts already sum it up well :)

So the video as a whole cannot be treated like a user interface element. so the fullscreen shortcut is only allowed when the fullscreen button itself is in focus.

This is also my experience with accessibility audits, I thought it was permitted with youtube (keyboard shortcuts only work when the video has focus) but it failed the audit, and we had to disable it.

[patrickhlauke]

cross-referencing a lengthy discussion on wai-ig mailing list from 2 years ago ... i think the conclusion at the time was that no, it doesn't https://lists.w3.org/Archives/Public/w3c-wai-ig/2019JulSep/0021.html

so the fullscreen shortcut is only allowed when the fullscreen button itself is in focus

which then makes the shortcut pointless since the user isn't "shortcutting" anything, they had to reach that button ... and might as well just hit space/enter.

[scottaohara]

Agreed. If the actual control needs to be focused to use the keyboard shortcut, then it might as well not be implemented at all which seems detrimental to helping people.

[patrickhlauke]

it's a very weird decision not to see the whole of the video player as a standalone component of sorts. once focus is anywhere in the player, shortcuts should be allowed. just for myself, i can't count the number of times i've taken advantage of these sorts of shortcuts for youtube etc as a user ... including some hidden power-user features like the "rewind 10 seconds" / "skip ahead 10 seconds" which youtube has, but just doesn't provide buttons for (j and l, where k is also a shortcut for play/pause...)

[bskibinski]

I think this decision is partly made to keep things "simple, understandable and enforceable". When you start to introduce exceptions for certain components, it gets really difficult to come up with a definition what an "interface element" means.

you could make this argument for a lot of components on your site, thus in effect making screen reader navigation more difficult: if a "video player" is seen as one interface element, then why not X and Y...

I think the definition is fine how it is now. And you don't have to remove keyboard shortcuts, you can also pass this criterium by offering one of these two options:

• Turn off: A mechanism is available to turn the shortcut off;
• Remap: A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);

[patrickhlauke]

thus in effect making screen reader navigation more difficult

not about screen readers...but voice control

you can also pass this criterium by offering one of these two options

third option: have shortcuts, just not single character key ones (i.e. use a modifier key + printable character, or use a non-printable one like F1-F12 keys etc)

[mraccess77]

In a practical matter this is what will happen - a feature will be introduced to disable single key shortcuts for a commonly used 3rd party video player. Authors who embed the players will want to meet WCAG 2.1 and will just always set the player to disable shortcut keys. People who benefit from single key shortcuts will no longer have them within the player. We can speak idealistically and say that a dialog could be created to change them or a user option can be created to disable/enabled, etc. - but experience has taught that those idealistic cases are less likely in this highly used scenario. For learning management systems so forth I'd expect those systems to build out more specific options giving the user flexibility.

[detlevhfischer]

Authors who embed the players will want to meet WCAG 2.1 and will just always set the player to disable shortcut keys. People who benefit from single key shortcuts will no longer have them within the player.

Unless I misread the SC, it is equally valid to enable single key shortcuts (e.g. on players) by default, and offer users an option to change that in settings, so I don't see the practical issue.

[mraccess77]

Page authors could add a setting somewhere on the page that updates the disabled attribute on the iFrame - yes - in reality I doubt many folks will be doing this. Ideally it would be a setting within the video player itself.

[detlevhfischer]

I have drafted a Proposed Working group answer for discussion (to extend the 2.1.4 Understanding text) but since I am not a speech input user, I have contacted @KimPatch to check whether she expects disadvantages when considering a video player as a whole a user interface component and allowing single key character shortcuts on once it receives focus.

[KimPatch]

@detlevhfischer I think the bottom line is speech Input users need to have the choice to turn single key shortcuts off regardless of pretty much anything including focus.

One of the problems with single key shortcuts is if the user doesn't notice where the focus is and speaks, there is big potential for disaster. A simple phrase can spew a dozen keyboard shortcuts. This can wreak a lot of havoc requiring sometimes very involved steps to step everything back or even figure out what happened. This is the kind of thing that produces extreme frustration, slows people way down, prevents them from using programs at all, and prevents other folks from recognizing that they can do work even though they use assistive technology. It is extremely common to do something without realizing where the keyboard focus is, regardless of the input method you use. The key here is to give speech input users the ability to remove the especially potentially disastrous penalty for not noticing so they can put more of their cognitive abilities toward their work.

[patrickhlauke]

@KimPatch could we press you for a more specific answer here? the SC does have an "Active only on focus" exemption. does a compound/complex widget like a video player constitute a "user interface component"? otherwise, it makes the exemption pointless for most scenarios.

[mraccess77]

In the case of the video player - it's often embedded and the person embedding it doesn't have a way to turn on or off that feature for many players. Since the feature only uses the keys when the embedded video is focused it would only trigger changes in the video if accidently invoked rather than impacting the whole page.

[detlevhfischer]

Proposed Working group answer for discussion (to extend the 2.1.4 Character Key Shortcuts Understanding text):

---

Video players in web content often support a number of single key shortcuts, for example, to start and stop the video, mute/unmute the video, call up the full screen view, or move the position on the timeline. These shortcuts are very helpful for keyboard users (and any user aware of these shortcuts). Video players are often embedded and the author often may not have a way to turn on or off single key shortcuts. However, since the shortcuts only have an effect when the embedded video is focused, any effects would be limited to the video rather than negatively impacting the page on which it is embedded.

For the purposes of SC 2.1.4, a video player and similar self-contained media players that receive keyboard focus as a whole before focus moves on to sub-elements like play/pause, settings or timeline controls, can be considered one user interface component and thus fall under "Active only on focus".

---

@KimPatch please comment if you think there are still issues that we have missed. I'll wait a few days and then mark this "ready for survey". Thanks @mraccess77 for additional points, which I have included in my proposed WG answer.

[patrickhlauke]

if accepted, this will obviously need to be clarified/codified in the understanding for 2.1.4 (effectively, expanding the "on focus" to "on focus within a complex component")

[detlevhfischer]

@patrickhlauke feel free to amend the text if this increases chances of acceptance...

[bskibinski]

@KimPatch could we press you for a more specific answer here? the SC does have an "Active only on focus" exemption. does a compound/complex widget like a video player constitute a "user interface component"? otherwise, it makes the exemption pointless for most scenarios.

I think she already clarified this with this sentence: "One of the problems with single key shortcuts is if the user doesn't notice where the focus is and speaks"

By treating the entire iframe as one component, it only raises the chance that you have the focus on something that uses single key shortcuts and thus having a bad time when using speech input. At least, that's how I read it. But I'm curious to hear the answer from her.

Also calling it pointless with the current implementation is a bit strong I think. There is a valid solution by giving users a choice to enable/disable them. But yes it will cost a bit more work to implement. This should probably be a browser setting or something along those lines. Maybe we could push them towards a proper solution?

Also @mraccess77 about video players that don't support disabling shortcuts: You should file a bug report, stating you can't use/embed their player because it causes a11y issues, I've done this with Vimeo with succes. I told the client we couldn't implement the player, because they would fail their audit, and we had to wait for an update of Vimeo (or they can choose to get a worse audit score).

[mraccess77]

A few of us had commented to Vimeo on that. I fear that most sites will just disable keystrokes for the player now reducing accessibility for other people who need or want single letter navigation. Page authors will have to add a page control to help users toggle between this setting unless there is some UI setting built into the player.

[bskibinski]

Oh I agree that the consequence will be that it will be disabled everywhere, and I also don't like that. And relying on people on building their own solution (or filing bug reports) is not great either. But (if I understood Kim correctly) the proposal is to more or less ignore the speech input problem, that's also not great. I'm also not sure what's best here, the more I think about it, the more I think it should be browser setting, if possible.

[awkawk]

...could we press you for a more specific answer here? the SC does have an "Active only on focus" exemption. does a compound/complex widget like a video player constitute a "user interface component"? otherwise, it makes the exemption pointless for most scenarios.

In the definition of User Interface Control (a part of the content that is perceived by users as a single control for a distinct function) it seems clear that unless the video player is only playing a video and there are no other functions that it isn't a UIC on its own. There is also a note (An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be settable independently, they would each be a "user interface component.") that seems somewhat similar to a video player where there are multiple controls for play/pause, caption display, next, previous, etc.

I'm not sure that I agree with your proposed text, @detlevhfischer.

[detlevhfischer]

@awkawk fair enough - it's just a draft to be argued about. If the group thinks that the definition of UIC rules out a video player exception, that is perhaps unfortunate, but that is also a solution to the issue. In case that not thinking of the video case at the time of writing the SC and drafting the exception can be considered an oversight, the normative text may still be amended eventually? But I guess it would be difficult to scope the exception if it should cover things like a player.

If I understand correctly the different modes of speech input available in tools like Dragon, I would imagine unexpected things could happen when speech input users watch a video and forget to revert to an input mode where some more explicit command is needed ( so that 'f' will not trigger full screen mode, for example). But others like @KimPatch should weigh in on this.

[awkawk]

@detlevhfischer yes, as you know I'm always up for a discussion and am happy that we can do so comfortably.

I worry also that the video player example is just one type of situation where this can come up and once you get into rich application functionality (e.g., online video editor, videoconferencing tool, word processor, HR tool, etc) where people will be performing tasks repetitively and looking for interaction efficiency the question of separation of focus and shortcut targeting comes up a lot. This may be what you are saying about scoping the exception.