Role=tablist currently only supports role=tab as children, but should support button?

[accdc]

I'm not sure if this has already been filed, but just in case, it's a common need to have associated action buttons that relate to individual tabs, such as a menu button, Edit, Delete, or other command type.

In practice, it should be possible to add these as siblings to their associated role=tab within the same tablist, since it doesn't make sense to render all such command buttons outside the tablist container.

According to the 1.3 ARIA spec however, no other role other than tab is allowed within role=tablist, making all such implementations invalid.

Can this be raised as a feature request if not already present?

[scottaohara]

this is one of the use cases for the aria-actions proposal though. seems more like that should be the way forward, rather than allowing buttons and then coming up with competing recommendations for how they need to be supported from keyboard and AT UX perspectives, vs how they would be supported via aria-actions.

[smhigley]

Yup, this seems like it'd be covered by #1805

[accdc]

I read the referenced issue, but it doesn't make any mention of which roles are accepted as a child of role=tablist or having this updated in the ARIA spec.

Please correct me if I'm wrong.

[scottaohara]

The point would be having the secondary action as part of the tab. No need to extra buttons then.

[accdc]

Do you know how long it will take for this to be supported?

I have a team that is working on a tab implementation right now and it needs to have supporting action buttons, and according to the ARIA spec this is impossible to do.

One possible solution is to just do it anyway because there is nothing else available right now for doing this, but I would like to know if there is a workable solution available that I'm unaware of.

[accdc]

So I just ran a bunch of tests on the following markup, and it works equally accessibly using JAWS and NVDA in Chrome, Firefox, and Edge, as well as in Safari on iOS using VoiceOver.

<ul role="tablist" style="list-style: none;" >
  <li>
    <a id="tab1id" role="tab" tabindex="0" aria-selected="false" > One </a>
    <button tabindex="0" aria-describedby="tab1id" aria-haspopup="true">Action</button>
  </li>
  <li>
    <a id="tab2id" role="tab" tabindex="-1" aria-selected="false" > Two </a>
    <button tabindex="-1" aria-describedby="tab2id" aria-haspopup="true">Action</button>
  </li>
  <li>
    <a id="tab3id" role="tab" tabindex="-1" aria-selected="false" > Three </a>
    <button tabindex="-1" aria-describedby="tab3id" aria-haspopup="true">Action</button>
  </li>
</ul>

If this markup is already accessible across all mainstream browsers and ATs and browsers, why should it be invalid according to ARIA?

I'm happy to talk about this at the next meeting.

[scottaohara]

what is the expected keyboard interaction for that supposed to be?

if a tablist is expected to use arrow keys to navigate through tabs, are the buttons now making 2 focus stops for each tab? extra descriptions to let people know the more actions/dismiss buttons exist?

nvda and jaws under default settings will turn off forms mode if keyboard focus moves to a button from a tab, so that'd sort of mess up the expected keyboard functionality of this for the many users who just use default settings.

i'm not saying that browsers won't expose the above markup, as you've likely tested yourself. but the user experience about this seems like it could get messy as well, regardless of support.

maybe an instance where an aria-controls/controlledby association could help - but that'd again be another thing that would have to actually be implemented by AT to communicate.

[accdc]

In this case you arrow between the tabs as normal, then press Tab to reach the associated button, otherwise the button has no tab stop in the same fashion as a tab that is not focused. There are only 2 tab stops at any given time, one for the tab and the second for the associated button. Logically this makes sense because these are two different controls.

Yes it would be nice to have all this happen automatically, as the action button project I think is meant to do, however right now this is the only way I can think of to provide an accessible solution that works right now.

If you can think of a better way of doing this that is already supported equally across all mainstream ATs and browsers, please let me know.

[scottaohara]

i see, forgive me for not understanding this since i was just looking at the markup snippet and wasn't clear on the behavior you were intending. TBH, I've seen people try to do similar and they just try to keep everything in the tab or arrow key order, or none of the buttons are in the tab or arrow key order, and then complicated aria-label/description messages are given to let people know about the sibling controls.

That said, i get where you're coming from. i don't intend for my responses to imply that i don't understand needing to help a client / product team now. And two focus stops for each tab, regardless of if you want to get to the more actions or not. That's definitely not the worst thing in the world. But I'm generally wondering where this idea (loosening allowances to provide a 'valid' solution to an immediate problem) stops (or should stop).

For instance, why not allow buttons alongside options or menuitems in their respective listboxes or menu/menubars? i'm not saying that to be facetious, at all. Truly, why just make a change to allow buttons in tablists? Why do we have any of these rules to limit children if browsers / AT can handle it? If the rational was that this sort of nesting wasn't supported before, then we should be looking at how things have changed and reexamine if those rules still make sense. Are these sorts of limitations making an unnecessary glass ceiling for the types of widgets that could be created?

More directly to your question, of what to do right now - well, without any change to the ARIA spec i'd personally say go with what you think works best / has the best support and makes sense for the users of that product. Does that mean the spec should change to say it's allowed? For that, I dunno. Definitely beyond just my opinion matters here, so I think this is a good topic for the group.

I will just say that you can similarly do a lot of 'invalid' stuff with HTML now that has no negative user impact. You can even do some valid nesting with HTML that results in rubbish UX - but the content models remain unchanged either way.

I'd also wonder if a spec change to allow for this would have any impact on aria-actions, which this sort of scenario was one of the use cases for that proposal. Does changing the spec to allow for this sort of stop-gap help or hurt aria-actions, while we wait for the potentially better solution. Will people (developers/implementors - not users) need/want aria-actions if there is a "good enough" solution now?

FWIW, I really do appreciate you asking this question. I think there's a good conversation that can happen here. Regardless of how this may read, my mind is not actually made up. I just don't know if it's a good idea or not.

[stes-acc]

Anyway, regardless how this turns out, I strongly expect that button roles in role tablist will be explicitly allowed officially at the very end, extending HTML5 or ARIA in HTML content rules for elements and affects related rulesets for checking.

I mainly think of explore by touch scenarios in mobile devices, where function of a control should also be denoted by its role.

Otherwise this will be remain unresolved which will cause much waste (incident reporting, discussions, time, money, energy consumption, storage) in industry which can't be in the interest of anybody.

[accdc]

Thanks for the discussion today.

Based on the WG feedback, I've modified the original code to use aria-actions as a forward-thinking approach that is already accessible across mainstream ATs and browsers.

1. The below construct is meant only to have 2 tab stops, one for the active tab, and the second for the associated action button.
2. As focus moves between each tab using the arrow keys, the tabindex for the associated tab is also changed so that any non-focused tabs will also have their associated action button taken out of the tab order.
3. When the user arrows to the desired tab, pressing tab will then set focus to the associated action button.

Attached is a simple test file that demonstrates this behavior.

This implementation was successfully tested using the latest versions of NVDA and JAWS in Chrome, Firefox, and Edge on Windows, as well as on iOS using VoiceOver in Safari for touch accessibility.

<ul role="tablist" style="list-style: none;" >
  <li>
    <a aria-actions="act1id" id="tab1id" role="tab" tabindex="0" aria-selected="false" > One </a>
    <button id="act1id" tabindex="0" aria-describedby="tab1id" aria-haspopup="true">Action</button>
  </li>
  <li>
    <a aria-actions="act2id" id="tab2id" role="tab" tabindex="-1" aria-selected="false" > Two </a>
    <button id="act2id" tabindex="-1" aria-describedby="tab2id" aria-haspopup="true">Action</button>
  </li>
  <li>
    <a aria-actions="act3id" id="tab3id" role="tab" tabindex="-1" aria-selected="false" > Three </a>
    <button id="act3id" tabindex="-1" aria-describedby="tab3id" aria-haspopup="true">Action</button>
  </li>
</ul>

test.zip

[stes-acc]

@accdc I missed the discussion yesterday due to an internal townhall meeting .. has your question been resolved/answered? Was your example accepted as being valid and applicable?

[accdc]

Yes to both, it was answered and valid.

I added aria-actions to ensure forward compatibility, and the accessibility should remain the same since it has to in order for aria-actions to work correctly within browsers and ATs when implemented in the future.

Also, this implementation is already similar in construct to other aria-actions examples being worked on right now within the APG.

[spectranaut]

Just for completeness sake, here is a link to the meeting where we discussed this issue during triage: https://www.w3.org/2024/08/29-aria-minutes