Manual activation tabs is confusing when aria-selected alone is seperate from focus

[accdc]

This is in regard to the example at https://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-2/tabs.html

I received a complaint that it is confusing for aria-selected not to match focus, especially since aria-controls is announced on the element that has focus implying that this is currently active yet this does not match aria-selected, so it is not clear what the state is for the currently focused tab when arrowing.

Also this does not match the paradigm for other selectable widgets such as role=listbox, where it is invalid to use aria-selected like this in the same manner when aria-multiselect is not set to true.

[mcking65]

@accdc commented:

I received a complaint that it is confusing for aria-selected not to match focus,

Bryan, wouldn't it be far more confusing if the selected state did follow focus but the tab wasn't actually selected and displayed? That would not be valid.

especially since aria-controls is announced on the element that has focus implying that this is currently active yet this does not match aria-selected, so it is not clear what the state is for the currently focused tab when arrowing.

I really don't see much value in aria-controls in the tabs pattern, at least not in implementations where the tablist is adjacent to the tabpanels. But, that aside, assuming we want to keep it in the pattern, putting aria-controls on a tab that is not selected is not necessary. You could leave it off without any downside. However, as I pointed out in issue #293, I don't think we should be changing the pattern to state that you should not put aria-controls on each tab in order to avoid excess screen reader verbosity. That should be addressed by either browsers not exposing invalid relationships or screen readers checking the validity of the relationship before saying there is one.

Also this does not match the paradigm for other selectable widgets such as role=listbox, where it is invalid to use aria-selected like this in the same manner when aria-multiselect is not set to true.

Why do you say it is not valid? There is nothing that says selection must follow focus in a single select. In fact, we explicitly explain that in the section about making the decision of whether to make selection follow focus. You can do the same kind of thing in a list box. Imagine a listbox that chooses which folder is displayed in an adjacent panel. If it takes time to load the panel, you would not want selection to follow focus. The same logic applies for trees as well.

I think the bottom line here is that the JAWS implementation of aria-controls support is not helpful.

[devarshipant]

With aria-controls, JAWS 17 / 18 speak "Use JAWS key (insert) + Alt + M to move to controlled element," thus stirring a user to move to the target panel referenced by aria-controls. It may have its drawbacks, but it is effective in creating a relationship between the active tab (role= tab) and its panel (role = tabpanel).

[accdc]

The reason I was given, is that it is confusing when focus is set to a toggleable active element when the state of that toggle is not clearly conveyed. This is particularly an issue for those with cognitive impairments.

To contrast in testing, this is why I do it differently on this implementation, because it specifically addresses this issue for these user types. http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Tabs/ARIA%20Tabs%20(Internal%20Content)/demo.htm

To me this is much clearer, because the focused element still follows the single select paradigm as documented in the ARIA Tabs spec, while also allowing for manual activation without being confusing to any user groups about the purpose of the tab that currently has focus.

The use of aria-controls is small in comparison and would be a good idea to set only on the currently expanded tab.

[mcking65]

@accdc, In your implementation at: http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Tabs/ARIA%20Tabs%20(Internal%20Content)/demo.htm

You are using aria-expanded instead of aria-selected to communicate witch tab is active. In that example, why are you using aria-selected? Selection is following focus but doesn't seem to be communicating anything. In fact, I think it makes the experience harder to understand because you have a tab that is both selected and collapsed. What does that mean? Normally, you can act on elements that have focus so focus is sufficient for communicating that the element is operable.

I would argue that using aria-expanded on tabs is inconsistent with the definition of aria-expanded. The tab is not a toggle. You can't collapse an expanded tab by activating it. I suppose you could add aria-disabled to the active tab. But, that just adds even more complexity and verbosity.

On the other hand, using aria-selected to communicate which tab is active is more consistent with the specification. It is also more consistent with similar experiences in native applications.

In this discussion, it is important to remember that the purpose of the ARIA is to describe the interaction model to the assistive technology. In the authoring practices, we are working on using ARIA in a way that is consistent with the specification and consistent across patterns. In so doing, we create UI that assistive technologies can reliably interpret.

Given a UI that is implemented in a way that is consistent with the specification, it is the job of the assistive technology to interpret that UI and make it understandable. Thus, if there are issues with understanding in this case, then I believe that problem falls squarely on the design of the assistive technology being used.

One of our primary goals with the authoring practices is to provide assistive technology developers with official reference implementations of ARIA. This is something they have never had. Thus, it has been very difficult to build assistive technologies that tap the true potential of ARIA because so many critical details have been left up to the guesses and hunches of well-meaning individuals rather than to consensus among working group members and other experienced readers of the specification.

I think agreement on simple details, such as the use of aria-selected vs aria-expanded on tabs, especially on very common patterns, makes it significantly easier for assistive technology developers to make really high quality experiences and thus more likely that they will. It also reduces confusion in the engineering community.

At the root of this issue is how aria-controls is treated by assistive technologies. Right now, it is causing more damage than good because JAWS is rendering aria-controls relationships even when the controlled target does not exist. I suppose we could put a requirement on browsers not to expose the relationship in that case; that would help AT developers. Freedom Scientific have also rendered the relationship in a manner that adds a lot of verbosity and complexity, which is kind of sad.

[css-meeting-bot]

The Working Group just discussed aria-expanded on tabs.

The full IRC log of that discussion

<AnnAbbott> TOPIC: aria-expanded on tabs
<jamesn> https://github.com/w3c/aria-practices/issues/459
<AnnAbbott> bg: selected is different than expanded for multi-select
<AnnAbbott> mck: use aria-current instead?
<AnnAbbott> mck: expanded tab cannot be collapsed
<AnnAbbott> bg: aria-current not written into spec
<AnnAbbott> mck: aria-current is global
<AnnAbbott> mck: adjust pattern to use expanded or current?
<AnnAbbott> mck: have no example for multi-select
<AnnAbbott> mck: single select - don't need change to pattern
<AnnAbbott> bg: agrees
<jemma_ku> I think tab pannel is single select container.
<AnnAbbott> bg: aria-select not being announced unless aria-expanded also added
<AnnAbbott> mck: sounds like hack for old AT
<AnnAbbott> mck: clean up spec to put expanded on controlling not controlled element
<jemma_ku> s/expanded/aria-expanded
<jemma_ku> http://w3c.github.io/aria/#aria-current
<AnnAbbott> mck: change when multi-select
<AnnAbbott> mck: narrow #459 to multi-select?
<jemma_ku> http://w3c.github.io/aria/#aria-selected
<AnnAbbott> bg: agrees
<AnnAbbott> bg: authors using APG as be-all, end-all so if use case isn't included, not used
<AnnAbbott> bg: if supported, include in example/design pattern
<jemma_ku> s/single select container/single select container in terms of individual tab and its controlled tab panel
<AnnAbbott> mck: for consistency: if element that expands also collapses, use that semantic
<jamesn> GitHub: https://github.com/w3c/aria-practices/issues/459
<AnnAbbott> mck: #459 is multi-selection and include example for next year

[mcking65]

@accdc, based on our recent discussions, I believe we have consensus that:

1. The current two tabs examples, which are single-select and use aria-selected on the tab to communicate which tabpanel is displayed, are both consistent with the specification and other single-select widgets.
2. In multi-select tablists, a state or property other than selected is needed to communicate which tabpanel or tabpanels are displayed.
3. If activating a tab in a multi-select tablist can alternately show and hide its associated tabpanel, aria-expanded is appropriate because the tab element functions as an expand/collapse toggle.
4. If a multi-select tablist can display only one tabpanel, and if one tabpanel is always displayed, then aria-current is appropriate.

As I re-read the tabs pattern it strikes me that the pattern would become complex and hard to understand if we weave in all the necessary changes to describe multi-selection and tab sets that can have multiple panels displayed or toggleable panels. The vast majority, probably 99% of tab sets out there probably fit into the single-select model where the tabs are either automatically or manually activated.

Rather than modify the existing pattern to accommodate the above points, I have modified issue #341 to propose that we draft a separate design pattern for multi-select tabs and then complete issue #342 to add examples of the pattern.

Do you agree that this summary of conclusions reflects our discussion and that issues #341 and #342 are a resolution plan that addresses the concerns raised in this issue?

[mgifford]

I'm curious where this is at right now.

We are searching for a best practice for https://www.drupal.org/project/drupal/issues/3035408