Elements with the "tablist" interactive role must be focusable
Closed this issue · 6 comments
Hello, I think the interactive-supports-focus rule is being applied incorrectly to the "tablist" role. According to the ARIA spec, while child elements with the "tab" role should be focusable, there is no indication that the containing "tablist" element must be focusable.
oh yeah, I think you are correct, if I'm not mistaken aria recommends the tabpanel to be focusable, but I guess the tablist is not really a concern, right? I will take a look at this :D
@vhoyer As I understand it's recommended to move focus into the tabpanel after a tab is activated. tablist is just a container for tabs, which themselves should be focusable.
https://www.w3.org/TR/wai-aria-1.2/#tablist
I think I get it, the thing is that a tabpanel is a composite widget. WAI-ARIA has this to say about composite widgets:
Authors SHOULD ensure that a composite widget exists as a single navigation stop within the larger navigation system of the web page. Once the composite widget has focus, authors SHOULD provide a separate navigation mechanism for users to navigate to elements that are descendants or owned children of the composite element.
So I guess it's kind of a gray area whether we have them focusable or not, because I guess it depends on the implementation, that said, non of the example provided by the wai aria practices have the tablist focusable, so I guess you are right, I guess we should ignore composite roles when checking for focusable elements.
I was also checking the implementation of the jsx library, and the implementation there is the same here. As a workaround I guess you could add a tabindex="-1"
reference:
https://www.w3.org/TR/wai-aria-1.2/#tablist
https://www.w3.org/TR/wai-aria-1.2/#composite
https://www.w3.org/TR/wai-aria-1.2/#managingfocus
https://www.w3.org/TR/2021/NOTE-wai-aria-practices-1.2-20211129/examples/tabs/tabs-1/tabs.html
https://www.w3.org/TR/2021/NOTE-wai-aria-practices-1.2-20211129/examples/tabs/tabs-2/tabs.html
https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/blob/main/src/rules/interactive-supports-focus.js
EDIT:
well, actually, the section "managingfocus_authors" say that tecnically the focus should be on the container (tablist), not the children (tab), since we should only have one tabstop for the hole tablist and no tabstop at the tabs, while the tabs are focused alternatively using the host language (javascript, afaik). But then again, the last time I made a tablist, I handled the focus directly with changing tabindex on the other elements, since this is easier to do with vue/react as compared to vanila.
And the spec is always referring to the use mostly in vanilla, so I guess it's neither broken, nor correct. as @jessebeach mentioned on a similar issue on the jsx counterpart of this library:
The tablist role is creating the violation here. Technically, it is considered a composite, which is a widget and interactive: https://www.w3.org/TR/wai-aria-1.2/#tablist
Put tabindex="-1" on it and the violation will go away.
reference:
https://www.w3.org/TR/wai-aria-1.2/#managingfocus_authors
jsx-eslint/eslint-plugin-jsx-a11y#404
Conclusion/TL;DR:
This is an edge case, I don't think I will add a PR for this, but feel free to yourself. I don't think this is completely wrong and I don't think it's completely correct. For now, you may add tabindex="-1".
@vhoyer thanks for investigating. It does seem pretty unclear, so I'll just use a workaround for now.
P.S. Is it possible to configure the rule to skip certain roles? It doesn't appear so from the documentation.
BTW I just realized that I only get this warning when I add a handler for certain events, such as "key<up|down|press>" and "click", to the element with the "tablist" role. It works for my use case because the event bubbles from child elements that are focusable.
oh, in that case the rule is doing it's job correctly, and you should skip this instance where to you this is not completely relevant, or add the tabindex workaround, just keep in mind to make the children tabs tabbable for accessibility through the keyboard, I'd recommend closing the issue :D