Should Chapters Buttons be "selectable"?

[gkatsev]

Description

As part of #3472, we're making chapter menu items "selectable" so that they show up correctly in the UI. However, this is strictly the correct thing to do from the perspective of accessibility and screen readers.
We should think about what the control tries to achieve and what the correct accessibility implications for this are. Then, we should try and address those as best we can.

[OwenEdwards]

The selectable option for menu items controls whether they are given the ARIA role of menuitemcheckbox, or simply menuitem; it then affects whether the item can be marked as selected with CSS styling (vjs-selected) and the aria-checked attribute.

This is analogous to the highlighting of selected menu options in this ARIA example: http://oaa-accessibility.org/example/26/ (note that this example contains some out-of-date ARIA implementation, and is included just to illustrate the visual effect of a menu item being selected).

In fact, there needs to be some further consideration of whether the selectable menu items are strictly menuitemcheckbox (multiple independently selectable options, like checkboxes), or menuitemradiobutton (selecting one option unselects all other options, like radio buttons) - in the case of the captions menu and the subtitles menu, the latter would seem to be the case.

However, the Chapters menu is a somewhat hybrid control, more similar to the progress bar. A user may select one item from the menu (like clicking on the progress bar), but as playback progresses, the chapter which is currently playing will change. Additionally, the WebVTT format for Chapters explicitly allows nested chapters (although video.js may not support them currently). So the concept of selected for Chapters doesn't really map to what a screen reader user, or sighted user, would expect, especially if the selected item doesn't change as playback progresses.