w3c / aria-practices

WAI-ARIA Authoring Practices Guide (APG)
https://www.w3.org/wai/aria/apg/
Other
1.21k stars 347 forks source link

Tablist: Clarify focus management when multi-selectable #643

Open 0ddfell0w opened 6 years ago

0ddfell0w commented 6 years ago

The tablist's keyboard interaction for the Tab key states

Tab: When focus moves into the tab list, places focus on the active tab element

This raises interesting questions about the multi-selectable tablist. If a tablist is multi-selectable, should there be something that prevents the only selected tab from being unselected? Without such prevention, it's possible there is no active tab – where should focus go in that case?

ZoeBijl commented 6 years ago

@0ddfell0w when a tablist is multi-selectable there aren’t multiple tabs open right? Or am I mistaken?

0ddfell0w commented 6 years ago

I have the same question. A github search for [role=tablist][aria-multiselectable=true] brings up mostly accordion implementations, so I think the idea is probably to have multiple tabs showing (or none)

mcking65 commented 6 years ago

Yes, the original intention of the spec is that when a tablist is multi-selectable, that would mean it can have more than one tab open. The model hear would be similar to other multi-selects where the first selected item receives focus when focus moves inside the tablist via the tab key.

That said, we re-did the accordion pattern to not use tabs. The reason is that you cannot put the tabs inside of a single tablist container in most accordion designs. A fragmented tablist does not make sense.

Similarly, designs with a tablist where multiple tabpanels can be simultaneously displayed and all the tabs are inside of a single, visually contiguous tablist are probably very rare.

There could potentially be another use of multi-select in tabs. A traditional tab set where only one tabpanel is displayed at a time could support manipulation of sets of tabs, e.g., delete several at a time. If selected signified which tabs were the target of operations like delete, move, etc., then a different property, such as aria-expanded, would need to represent the tab that that is displayed.

0ddfell0w commented 6 years ago

@mcking65 we'd like to author such a multi-selectable tablist example and have it sit alongside an accordion example, if only to show that multi-selectable tablists are not the ideal way to implement an accordion. That said, the following excerpt from the 'tabs' entry in the APG makes such a multi-selectable tablist seem questionable

When a tabbed interface is initialized, one tab panel is displayed and its associated tab is styled to indicate that it is active. When the user activates one of the other tab elements, the previously displayed tab panel is hidden, the tab panel associated with the activated tab becomes visible, and the tab is considered "active".

Could we re-word that paragraph to de-couple "tab-is-active" from "panel-is-showing" – or somehow recommend against multi-selectable tablists in a way that points to the APG's accordion example as an alternative?

ZoeBijl commented 6 years ago

I’m not entirely sure how you’d activate multiple tab panels at once, but I imagine it’d be something like:

  1. Select multiple tabs with a modifier key like ctrl/cmd
  2. Press the activation key (space)
  3. Activate the selected tabs and show their related panels
  4. Profit

If that’s the case, something like this might work:

When a tabs widget has aria-multiselectable set to true, multiple tabs can be active and their related tab panels should be shown. Tab panels that are not associated with any of the selected tabs should be hidden.

0ddfell0w commented 6 years ago

@MichielBijl the blurb you suggest applies only to the multi-selectable tablists that @mcking65 referred to as rare, correct?

Similarly, designs with a tablist where multiple tabpanels can be simultaneously displayed and all the tabs are inside of a single, visually contiguous tablist are probably very rare.

--

For multi-selectable tablists with multiple panels showing: Should we just recommend an accordion for these cases? We could then keep the existing note that >"When the user activates one of the other tab elements, the previously displayed tab panel is hidden"

For multi-selectable tablists where one panel is showing: Can we explicitly recommend using aria-expanded state to represent that a tab's panel showing, and use aria-selected to represent that any other actions (e.g. deletion) will apply to a tab.

ZoeBijl commented 6 years ago

@0ddfell0w correct.