Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider semantics of pop-up menus #262

Closed
terrill opened this issue Jan 15, 2017 · 1 comment
Closed

Reconsider semantics of pop-up menus #262

terrill opened this issue Jan 15, 2017 · 1 comment
Labels

Comments

@terrill
Copy link
Member

terrill commented Jan 15, 2017

Clicking either the Captions, Chapters, or Preferences button triggers a pop-up menu with a list of options. In each case, the list of options is currently coded as a list of radio buttons since the user can only select one option from the set. However, this may not be the best choice of semantic elements for each of these menus. They were coded identically for consistency, so when a user clicks a button on the player control that has a pop-up menu, they know what to expect. However, selecting an option from each of the pop-up menus yields fundamentally different results. Therefore, maybe radio buttons might not be an appropriate choice for all three menus. Here are details and thoughts about each menu:

  1. Captions/Subtitles - the list of options includes available languages. Selecting an option results in captions/subtitles being displayed in that language. Radio buttons seem appropriate for this purpose.

  2. Chapters - the list of options includes chapters as defined within the chapter track (WebVTT file). Selecting an option results in the video advancing to the time at which the selected chapter starts. Radio buttons seem less appropriate for this purpose, and will particularly be insufficient once a deeper chapter structure is supported (i.e., sections and sub-sections within chapters, as per Issue Add full support for WebVTT  #13).

  3. Preferences - the list of options includes preferences categories (Captions, Descriptions, Keyboard, and Transcript). Selecting one of these categories results in a modal dialog appearing. It is unconventional and possibly confusing for users for a radio button to trigger a modal dialog. A more appropriate choice in this case may be to code the entire pop-up menu with role="menu" and each item as role="menuitem" with aria-haspopup.

I still think it's good for these pop-ups to be consistent with one another, so perhaps they should all be coded as menu items, as described above for the Preferences pop-up (not sure if that's feasible for nested chapters). Or maybe consistency isn't so critical since they each have such different functions.

Any thoughts about how to proceed? I welcome and appreciate any feedback.

@terrill
Copy link
Member Author

terrill commented Aug 17, 2019

This issue should have been closed a while ago. All popup menus are now coded with role="menu", the buttons that trigger them have aria-haspopup="menu", and menu contents are all menu items, not radio buttons.

@terrill terrill closed this as completed Aug 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant