You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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).
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
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).
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.
The text was updated successfully, but these errors were encountered: