Open 0ddfell0w opened 6 years ago
@0ddfell0w when a tablist
is multi-selectable there aren’t multiple tabs open right? Or am I mistaken?
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)
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.
@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?
I’m not entirely sure how you’d activate multiple tab panels at once, but I imagine it’d be something like:
If that’s the case, something like this might work:
When a tabs widget has
aria-multiselectable
set totrue
, 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.
@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.
@0ddfell0w correct.
The tablist's keyboard interaction for the Tab key states
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?