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.

Sign up for GitHub

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

Jump to bottom

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

Open
jjaeggli opened this issue Feb 28, 2022 · 10 comments
Open

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

jjaeggli opened this issue Feb 28, 2022 · 10 comments
Labels
agenda Include in upcoming Authoring Practices Task Force meeting Feedback Issue raised by or for collecting input from people outside APG task force question Issue asking a question
Projects
Tabs Pattern and Examples Development...

Comments

@jjaeggli
Copy link

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
Copy link

zelliott commented Mar 1, 2022

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
Copy link
Contributor

ZoeBijl commented Mar 1, 2022

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

@JAWS-test
Copy link

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

@jjaeggli jjaeggli changed the title The tab role does specify how it should be associated with the popup menu described in the Tabs pattern 3.24 The tab role does not specify how it should be associated with the popup menu described in the Tabs pattern 3.24 Mar 1, 2022
@a11ydoer a11ydoer added the agenda Include in upcoming Authoring Practices Task Force meeting label Mar 1, 2022
@ZoeBijl
Copy link
Contributor

ZoeBijl commented Mar 2, 2022

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

@JAWS-test
Copy link

JAWS-test commented Mar 2, 2022 •
edited

@ZoeBijl To my knowledge there is no way to enable the output of aria-controls. See w3c/aria#995

@jjaeggli
Copy link
Author

jjaeggli commented Mar 4, 2022

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
Copy link

zelliott commented Mar 4, 2022

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
Copy link
Contributor

mcking65 commented Aug 2, 2022 •
edited

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 mcking65 added question Issue asking a question Feedback Issue raised by or for collecting input from people outside APG task force labels Aug 2, 2022
@mcking65 mcking65 added this to Next Steps in Tabs Pattern and Examples Development Project via automation Aug 2, 2022
@mcking65
Copy link
Contributor

mcking65 commented Aug 2, 2022

Issues related to allowed children in composites:

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

@mcking65
Copy link
Contributor

mcking65 commented Aug 9, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
agenda Include in upcoming Authoring Practices Task Force meeting Feedback Issue raised by or for collecting input from people outside APG task force question Issue asking a question
Projects
Tabs Pattern and Examples Development...
  
Next Steps
Milestone
No milestone
Development

No branches or pull requests
6 participants
@zelliott @ZoeBijl @mcking65 @jjaeggli @a11ydoer @JAWS-test