Buttons

[mmcc]

This PR switches to using buttons instead of divs, as discussed in #1499. Just a note, this PR does not switch menu buttons over since that would require a substantial amount of refactoring from how things currently work. We plan on making that switch in a future minor release.

[heff]

Add a more descriptive comment about the bug, please

[heff]

Made some comments but otherwise lgtm.

[heff]

@OwenEdwards any thoughts on how "menu buttons" should be treated? e.g. the captions menu. Should they be switched to buttons too or another element?

[OwenEdwards]

Let's start by renaming 'menu button' to 'menu widget'! Semantically, this thing is a control widget with much more functionality than a button (but see below). Then, see my comments on #2155.

I want to clarify a point here though about the menus, which is about usability as much as accessibility:

Currently, the 'menu button' code is designed to work as a toggle button, which displays or hides the menu when clicked or activated by the keyboard (Space, Enter and Escape are supported).

However, in the CSS/skin, the menu is displayed on hover, so clicking on the menu button only toggles focus (highlight) onto / off the top item in the menu, which (to me at least) is confusing, because it's not actually doing anything to the video player, but there's a visual change.

When using the keyboard to control the 'menu button' (Tab to the control), pressing Enter or Space not only displays the menu, but also activates the top item on the menu, so the keyboard access is broken.

We need to make a decision on what we want clicking on the menu button to do for mouse/touch users, and whether we want that behavior to be changeable with a skin. Note that it's okay to have 'display menu on hover' and still maintain keyboard accessibility (see http://oaa-accessibility.org/examplep/menubar1/). Then, we need to fix keyboard access to menus, per #2155.

[gkatsev]

The quick fix to making menu buttons accessible is making the menus show up on :focus and :active as well as on :hover. In addition, we'd need to make the next <tab> key go into menu items.

[OwenEdwards]

:focus would be a quick fix to bring up the menu with keyboard navigation of the controls, but wouldn't resolve the issues of:

1. What should clicking on or keyboard activating the main button of the menu do? If nothing, then let's get rid of that functionality, and the button can stay as a <div> (wrapping a <ul>). But, if there's only one CC track specified, do we want to support a simple toggle button without a menu, like the native HTML5 players do?
2. Fixing how keyboard activating the main button of the menu also activates the top item in the menu. (This could be fixed by 1).
3. Ideally menu items should not be in the <tab> order, otherwise a long list of possible caption/subtitle languages would take a very large number of <tab> presses to get through to the next control widget. (Think of keyboard access to a <select> .. <option> combo box.) <tab> should go from control widget to control widget, while <enter>, <space>, <escape>, and the arrow keys should interact with the widget. This is part of Keyboard accessibility of control bar menus (e.g. captions, subtitles, etc) #2155, so for now menu items can stay in the tab order; they can be <div>s with role=menuitem, and the 'main button', if it stays as a <div> should have role=menu.