`useTab()` does not adhere to W3C ARIA APG regarding `aria-controls`

[nwidynski]

Provide a general summary of the issue here

The W3C APG Tabs Pattern and W3C WAI-ARIA 1.3 Spec indicates aria-controls SHOULD be set on each tab panel. We currently set the prop only when selected due to #837 (comment), but I'm wondering whether this was an oversight and panels should instead be forced to mount with display:none.

This is heavily impacting the design section of the Rotator RFC so I would like to gather feedback before committing. The context of this question is whether tab panels could exist in a collection, which may be virtualized, thereby also removing panels from the DOM. In this use-case, each Tab would cause a TabPanel to scroll into view.

I'm also questioning whether aria-controls would even be pointing to the TabPanel in this scenario, since the state being controlled isn't perceivability of the TabPanel but rather the scrollLeft of the scrollParent. Maybe a generic button group, an anchor list or possibly radio group, with aria-controls pointed to the scrollParent is more appropriate?

Furthermore, assuming aria-controls is pointing to a TabPanel and is set only when selected - Is it acceptable if its value were to temporarily point to a missing DOM element until the selected TabPanel is scrolled into view? This could happen when a Tab, pointing to a virtualized TabPanel, is selected and it takes a while to scroll the TabPanel into the visible rect.

@devongovett @majornista

🤔 Expected Behavior?

😯 Current Behavior

💁 Possible Solution

No response

🔦 Context

No response

🖥️ Steps to Reproduce

Version

latest

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

OSX

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[nwidynski]

@LFDanLu Sorry for the delay on the RFC, these questions are blocking at the moment.

[snowystinger]

This could happen when a Tab, pointing to a virtualized TabPanel, is selected and it takes a while to scroll the TabPanel into the visible rect.

This should solvable by immediately adding the TabPanel to the list of persisted keys? much like how focused items in a virtualized collection are never unmounted.

[nwidynski]

@snowystinger Yeah, I also thought that but postponed exploration until I know whether aria-controls should continue to be set on select only. I personally don't think it needs change, since the reverse mapping of aria-labelledby should suffice, but just checking here if there was any testing done when you made the original implementation.

Meanwhile, I lean on designing the rotation picker as a button group since the tabs pattern feels iffy for this use-case.

[snowystinger]

I do not know, but I'll ask with our accessibility team as well
@majornista if you have some insight into this issue

[majornista]

aria-controls should only be added to the Tab when the corresponding TabPanel is present the DOM, and in the current RAC and React-Spectrum component implementations, only the currently selected panel is rendered. Adding an aria-controls with an IDREF for a panel that does not exist in the DOM will be flagged by automated tests as an accessibility failure, which is why we are only adding it when a Tab is selected.

If the implementation of a Rotator/Carousel were to render more than one panel at a time, aria-controls should be included on each corresponding tab, or if you want to ensure that every tab has an aria-controls, @snowystinger's suggestion to use persisted keys is one possibility.

It should be noted that at present, only JAWS makes use of aria-controls, by providing a keyboard shortcut (Insert + alt + M) to move the virtual cursor from the element with aria-controls to the element with the corresponding id. There is no keyboard shortcut to move the focus back to the element with aria-controls.

Related articles/issues:

• What to do about aria-controls w3c/aria#995
• https://heydonworks.com/article/aria-controls-is-poop/

[nwidynski]

@majornista Thank you for the quick reply ❤️

While I understand it SHOULD be included on each corresponding tab that is present in the DOM, this isn't really feasible in a use-case, in which the selected tab is controlling the scroll offset of a tab panel container. This is due to the fact that both the tablist and the tab panel containers are scrollable independently and their scroll offsets aren't locked bidirectionally. Now if both tablist and panel container are virtualized, scrolling the former will lead to stale IDREF's.

I was therefore wanting to know whether its fine to only set aria-controls on the selected key, even though multiple tab-panel pairs are in the DOM. In case it's not, I will have to find a way to push all visible keys of the tablist into persisted keys of the controlled tabpanel container, which may be difficult to do efficiently.

PS: As I understood so far, this is a general question on aria-controls and doesn't have to do with tab role carrying this attribute, right? Just FYI, I was planning to have aria-controls on "button" elements in a "group".

PPS: Since selection of a tab only scrolls the tab panel into view, while not moving focused key of the controlled collection, I'm also skeptical of this shortcut even landing on the correct item in this case. At this point, wouldn't it be better to entirely omit aria-controls?

[snowystinger]

I was therefore wanting to know whether its fine to only set aria-controls on the selected key, even though multiple tab-panel pairs are in the DOM

I think a solution to this would be for the non-selected tabpanels, which are rendered but not accessible due to scrolloffset, should just have their roles removed. That would solve the issue of them being flagged as an error.

[nwidynski]

@snowystinger Very interesting, I haven't thought of that!

[devongovett]

I'm pretty sure only one tab panel should be "visible" at a time. In the APG example, the non-selected tabs are display: none which removes them from the accessibility tree. If you are mounting multiple at once (e.g. for an animation), then the non-current tabs should be inert, in which case they are also removed from the accessibility tree.. That's what RAC's shouldForceMount prop does. In all of these cases, I'm not sure that adding aria-controls pointing to an element that is not in the accessibility tree makes sense either. Regardless of whether it exists in the DOM or not, it does not exist in the accessibility tree.

[nwidynski]

@devongovett Does this still hold true when not employing the tabs pattern? Aka. tab -> button & tabpanel -> presentation - Having non-selected panels that are still visible be inert would be a problem, since I was planning to make the rotator work generically for all list collections, which would mean interaction is blocked on visible cells/options.

[devongovett]

If you want multiple panels to be visible at once, then the tabs pattern isn't the right one to follow. Tabs are specifically for displaying one panel at a time, and where the user has random access to each panel. So for a carousel, that would be something like the APG example: https://www.w3.org/WAI/ARIA/apg/patterns/carousel/examples/carousel-2-tablist/

If you want something that displays multiple "cards" at once and lets users swipe through it (like Material Design's https://m3.material.io/components/carousel/overview), then I'd just use one of our existing collection components with CSS scroll snapping for the swiping behavior.

Perhaps a screenshot or mock of the UI you're trying to build would be helpful.

[nwidynski]

Sure, I will include a preliminary excerpt from the RFC I'm working on. Also as a reminder, we're developing a library, not a specific UI component, so we don't know which content our user will try to display in a carousel.

While you will notice the top right says "tab list", one should really refer to this as the interaction pattern, not the ARIA pattern (e.g. could be a button group). What the RFC will be proposing is a generic scroll controller, akin to virtualizer, which enables any collection to become a carousel. This will basically offer a full-fledged carousel library, based on native scroll & CSS snapping instead of transforms and JS scroll.

Something like your Carousel Gist isn't supporting complex use-cases, for which rotation controls require layout information. One such example would be "next" having to be disabled when only disabled items are following, even though we haven't scrolled all the way to the end visually. Furthermore, features like infinite loops in a scroll container are really challenging and are something we are uniquely positioned for to implement generically with a CarouselLayout for a virtualizer.

Especially virtualization of the collection causes a bunch of a11y problems, which I'm trying to clear up on here. In this case, my ask is how each "tab" shall be connected to its collection item from an ARIA perspective (especially aria-controls) and whether rotation controls should be exposed to the tab sequence.

PS: @LFDanLu Hopefully this starts clearing up on the connection of my PRs 😅

[devongovett]

Still trying to follow what the interactions are in that screenshot. Is this navigating the items in the ListBox or is the ListBox within a carousel page?