I have a question about the aria role tablist
. Are tab elements the only allowed elements inside a tablist
. Here is an example DOM.
<ul role="tablist">
<li>
<a role="tab" href="#">My Tab</a>
<button class="close">X</button>
</li>
</ul>
Since <button>
is an interactive element it will be added to the accessibility tree. The spec says "Allowed Accessibility Child Roles" is tab
. Does that also apply to implied roles? If the tab role is moved to the <li>
then the question becomes moot?
You put the finger on a weak part of ARIA. There’s an ongoing discussion to address the issue of secondary actions like closing tabs in ARIA
You are right in your statement when it comes to the specification, but I’ll rephrase it a little:
tab
roles are the only allowed child roles inside a tablist
.
The nuance is that ARIA applies to roles, not HTML elements. You can place any HTML element directly under a tablist, as long as it does not have a role (or role="none"
). It’s also important that the specification mentions child roles, not roles deeper in the accessibility tree. So descending the DOM, the next element with a role other than none
, must be that of tab
.
<li>
has an implicit role of listitem
—hence it is not allowed as a child of an element with role tablist
. You could remove its role with <li role="none">
, which would at least provide a consistent no-CSS fallback.
The element with role tab
is expected to be interactive, so you couldn’t simply add it on the <li>
element without handling all interaction on it.
Any interactive element must not have interactive children. This poses an issue for the pattern.
Maybe the discussion on Github inspires you to some work-around.