The tab role does not specify how it should be associated with the popup menu described in the Tabs pattern 3.24

[jjaeggli]

The tabs pattern (https://w3c.github.io/aria-practices/#tabpanel) indicates that a popup menu, if present, can be activated via SHIFT + F10.

Shift + F10: If the tab has an associated popup menu, opens the menu.

In other cases where a popup menu is associated with a control aria-controls would be used to indicate that the control is associated with the menu element. However, in this case aria-controls for the tab is associated with the tabpanel. aria-expanded also has separate connotations from other popup-controlling elements, and therefore cannot be used to indicate whether the popup menu is open or visible.

The use of a popup or controls such as delete on a tab is a common pattern, as indicated by the document the possibility of including the delete option in the menu:

As an alternative to Delete, or in addition to supporting Delete, the delete function is available in a context menu.

As such the tab role should support the inclusion of a menu control on the tab so that the state of the menu can be understood. However, currently the tab role is child-presentational. Focusable children should be focusable according to presentational conflict resolution rules: https://w3c.github.io/aria/#conflict_resolution_presentation_none however the state of the menu of any associated focusable child will not be conveyed (or at least the behavior by the SR is unspecified).

In order to convey the state of the popup menu, a tab role should allow a child element which is a control of menu and provide popup menu semantics which are conveyed to the tab parent element. Additionally, these controls should be focusable by keyboard-only users.

Example:

https://codepen.io/zelliottm/pen/YzEJdrj

[zelliott]

However, in this case aria-controls for the tab is associated with the tabpanel.

aria-controls can point to multiple space-separated idrefs (e.g. aria-controls="foo bar"), so I don't see this as a blocker, but I'm curious what SRs would announce (if anything).

aria-expanded also has separate connotations from other popup-controlling elements, and therefore cannot be used to indicate whether the popup menu is open or visible.

Do you mind clarifying? Why can't aria-expanded be placed on a tab? https://www.w3.org/TR/wai-aria-1.2/#aria-expanded

[ZoeBijl]

I’m also curious about the aria-expanded thing—it’s not used for anything else at the moment.

[JAWS-test]

aria-controls is ignored by most screen readers https://a11ysupport.io/tech/aria/aria-controls_attribute. For example, JAWS has made a conscious decision to stop outputting aria-controls because it leads to unnecessary output

[ZoeBijl]

@JAWS-test is there a way you can still get at that information in JAWS?

[JAWS-test]

@ZoeBijl To my knowledge there is no way to enable the output of aria-controls. See https://github.com/w3c/aria/issues/995

[jjaeggli]

Here is where I see the use of aria-expanded defined:

https://w3c.github.io/aria/#tab

For a multi-selectable tablist, authors SHOULD ensure that the tab for each visible tabpanel has the aria-expanded attribute set to true, and that the tabs associated with the remaining hidden tabpanel elements have their aria-expanded attributes set to false.

Therefore aria-expanded should convey the state of of a tab as selected in a multi-select scenario. While it seems unlikely that that there is a scenario where someone would want to implement multi-tab selection and a menu, having to handle both cases would make implementation by SRs less straight forward. If attributes of the tab are to convey the state of the panel (hidden, visible) attributes of something else should convey the state of the menu or actions on the tab (expanded, collapsed, disabled). Complex conditions where a menu is disabled, or deleting a tab is disabled are potentially possible.

[zelliott]

Nice catch @jjaeggli. I agree that this is an issue. I wonder why multi-select tabs use aria-expanded... why not use aria-selected to indicate multi-selection like other selection widgets?

[mcking65]

What if we resolved this by recommending that that any tab with a context menu also have a visible menu button adjacent to the tab? That menu could be accessible by either using shift+f10 while focus is on the tab or by activating the menu button.

There is actually a problem with the shift+f10 approach; it requires hijacking the browser menu or overriding it completely. Neither option is very good. So, perhaps, we should not even suggest using shift+f10?

I know that including a menu button as a descendant of a tablist is not explicitly supported by the ARIA spec. It is also not explicitly prohibited either. I believe we have a few issues open in ARIA related to this. In practice, it does work with both browsers and AT.

[mcking65]

Issues related to allowed children in composites:

• w3c/aria#1486
• w3c/aria#1454

Still looking for issue directly related to allowing menubuttons in tablists.

[mcking65]

Could be resolved by: Secondary actions on items in composite widget roles · Issue #1440 · w3c/aria

As well as by allowing buttons inside of tablists.