Keyboard Accessible MenuItems and VolumeMenuButton #1519
Conversation
…ing tab navigation. Previously, they could not be navigated to via the keyboard. Fixs #1517. Tested via manaul cross-browser tests using keyboard navigation (chrome, firefox, safari, and IE 11 ).
|
Thanks for this! I added my thoughts to #1517. |
…nuitems become tab targets. The volume control bar now uses the vjs-lock-showing class instead of new class.
| @@ -717,7 +717,8 @@ easily in the skin designer. http://designer.videojs.com/ | |||
| } | |||
|
|
|||
| .vjs-default-skin .vjs-menu { | |||
| display: none; | |||
| z-index: -1; | |||
There was a problem hiding this comment.
I think we could use the hide-visually mix-in here instead of z-index. There's potential that a menu button component could be used somewhere where the menu wouldn't be covered by the the player.
There was a problem hiding this comment.
The .vjs-default-skin .vjs-menu selector is going back to using display: none based on your previous comment. So I don't it should be using hide-visually.
I don't think it makes sense to use visually-hidden for the volume bar, because then we have to manually undo all of the styles it entails and repeat styles we've already created.
Thoughts?
There was a problem hiding this comment.
Yeah, it doesn't make sense to use it on .vjs-menu with the other change.
I was mainly looking for an alternative to z-index for hiding it. Would height:0 or width: 0 work? That seems to basically be what youtube is doing. Alternatively we could add a .visuallyhidden class that contains the hide-visually styles, and add/remove that class to/from the volume slider when needed.
There was a problem hiding this comment.
I'm a little hesitant on the .visuallyhidden idea (although I experimented with it and does work alright). My first concern is that we also need to listen to hover in code rather than css. Secondly, I kinda like being able to use the lock/unlockShowing methods on menu, as opposed to manually adding/removing classes.
The width: 0 works a bit better. It winds up being more css because you have to explicitly style the vjs-menu-content as well as the vjs-menu. However, I think this might be a better solution. I'm gonna try to clean my experiments up and push them up.
Sound good?
| @@ -30,6 +30,12 @@ vjs.VolumeMenuButton.prototype.createMenu = function(){ | |||
| contentElType: 'div' | |||
| }); | |||
| var vc = new vjs.VolumeBar(this.player_, vjs.obj.merge({'vertical': true}, this.options_.volumeBar)); | |||
There was a problem hiding this comment.
@gkatsev I'm realizing that the volume menu button is broken by default because vertical is true by default here and nothing else is set up to handle that. If I set it to false it makes it work. Does the BC version set this to true somewhere or would that change break things?
There was a problem hiding this comment.
why would it be broken here? Seems to be working fine for us. It used to be broken when vertical wasn't quoted.
There was a problem hiding this comment.
When I test this PR and try to drag the volume handle with my mouse, the bar is horizontal but the mouse movement needs to be vertical. Are you seeing something different? To be clear, I think this issue existed before this PR.
There was a problem hiding this comment.
And by test I mean open /sandbox/index.html
There was a problem hiding this comment.
Ah, I see. There needs to be extra CSS that rotates it.
|
Made a few CSS changes but this should be good to go. |
|
I merged in my changes to get them out with the release. Let me know if you have any later thoughts and we'll get them in. |
|
I think they're good. Thanks @heff. |
Makes the volume control and menu items accessible via tab navigation on the keyboard.
Fix for #1517