Accessible Volume Menu Control Bar

[rpless]

Currently, when using the volume menu (i.e. configuring the player to use volumeMenuButton in the control bar) using tab to navigate the controls skips the actual volume bar. This happens because the menu is styled with display: none, so it can't be navigated to.
I think what should happen is that volume bar should be navigated to after the mute button. Since it has the tabindex it is meant to navigated to, so it should appear after you tab off the mute button. If this seems like a good addition, I'll put in a PR for it.

[mmcc]

I'm not sure I follow. Mind putting together an example that shows what you mean?

[gkatsev]

Yes, we need to do that.

@mmcc , we have a "volume menu control bar" that has the volume bar as a submenu that is only visible when you hover/click on the volume(mute) button.

[rpless]

@mmcc Sorry if I wasn't clear. Have a look at this: http://codepen.io/rpless/details/HaBtm/.
Tab until you reach the mute button. Then tab again. You won't have focus on the volume control bar that in theory comes after the mute button, rather another part of the webpage. Accessibility-wise I think it would make more sense to have the the volume bar gain focus next.

[rpless]

Also do you think this should happen for other menu's, such as closed caption? My feeling is that changing all of the vjs-menu's to do have this behavior would make all of those options accessible via keyboard navigation. Thoughts?

[gkatsev]

@rpless sounds like it should.

[heff]

The subtitles/captions menu tab interaction has been reviewed by a few people who know more about this stuff than I do (e.g. @gdkraus), so I'd be cautious to make a change like that to all menu buttons. The pattern is that you tab to the menu button you're interested, then hit space bar to activate the menu, then tab to the menu item you want, then hit space bar to activate it. If we always open a menu when you navigate to the button, you would have to then tab through all items in the menu before you could move to the next button. Imagine tabbing through 20 subtitles language options before you can get to the captions menu button. So I don't think we want that.

The volume control is different though because there's technically two controls going on there, the mute and the volume slider. It was probably overly optimistic to try to fit that into the same pattern as the other menu buttons. Check out YouTube's tab controls. For volume, the mute and the volume slider are independent tab targets, just like we want here. However the other menu buttons (settings, captions) work like I described above, requiring you to hit space bar to activate the menu. I think that's where we want to get to with this. Does that sound right?

[rpless]

Yeah, I agree. Pull Request #1519 includes the behavior for the volume control that you describe, but allows you to tab into other submenus.
I'll change it so that submenus need to be activated before you can tab into them, but it will still treat the volume control bar as a separate tab target that expands when tabbed to.

[gdkraus]

In fairness, it's been quite some time since I've looked at the accessibility of VideoJS. I would need to go back and look at it again before I could comment about it. I'll try to do that in the next few days.

[heff]

Closed by #1519