What to do about the rowgroup discrepancy between the spec and implementations?

[cookiecrook]

The first HTML-AAM results landed today in WPT. In particular, the table roles tests show that Chrome and WebKit treat thead/tbody/tfoot as ignored (literals none and "" respectively) rather than rowgroup from the HTML-AAM spec.

https://wpt.fyi/results/html-aam/table-roles.html?label=master&label=experimental&aligned

Do we need to resolve this to use rowgroup or should this be a case where the spec should reflect the current reality rather than requiring an arbitrary change without substantial user benefit?

[stevefaulkner]

@cookiecrook what counts as substantial user benefit? and why consider it arbitrary when they are defined in HTML as:

represents the block of rows

[cookiecrook]

I just mean that that browser and platform accessibility implementations haven't used them… Ever, as far as I can tell. I've verified this in Gecko, Chromium, and WebKit. They aren't reflected in any accessibility inspector, either.

As far as I know, there is no special accessibility behavior for thead/tbody/tfoot. I am aware there is is special behavior when printing large tables that span multiple pages of paper (the thead and tfoot are repeated on each page) but as far as AAMs and AT are concerned, these are ignored elements, and always have been.

why consider it arbitrary?

This is in the context of WPT tests for HTML-AAM. Passing these values would require a change in every browser that introduces risk without any user benefit that I can perceive, and possible cascade changes to a variety of assistive technologies.

what counts as substantial user benefit?

In this case any user benefit would be worth discussing. I don't see any.

Since the implementations are aligned and there isn't a user-driven clamor to support the rowgroup role as a new feature, I'd suggest that:

• the mappings for thead/tbody/tfoot be changed to ignored/none in the HTML-AAM spec.
• the rowgroup role be considered for deprecation in ARIA.

…unless there is some functionality specific to Windows that I'm missing in my Mac-side investigations of these browser implementations.

[cookiecrook]

These are thead elements (same for tbody and tfoot) in:

Chromium:

WebKit:

I can't find any representation of this in Gecko's dev tools. There's also no similar concept I'm aware of in the Xcode Accessibility Inspector for macOS or iOS. If you find something similar on Windows, please share.

[jcsteh]

Gecko normally chooses not to expose thead, tbody and tfoot because they don't really serve much of a purpose, especially given that tables always have a tbody. However, if you force an Accessible to be created (e.g. tabindex or aria-label), Gecko will create an Accessible and it will have the rowgroup role.

[stevefaulkner]

@jcsteh that makes sense, @cookiecrook @aleventhal does this sound reasonable?

default thead, tbody and tfoot have a generic role
if tabindex or accname present they are exposed as rowgroup?

[jcsteh]

To be clear, Gecko doesn't expose them with a generic role if there's no tabindex, aria-label, etc. They don't exist in the a11y tree at all, more like role="none". As I understand it, those two things are different, albeit subtly so.

[jcsteh]

Having said that, I think there's some general confusion around generic things that needs to be sorted out. For example, div and span map to role generic, but both Chromium and Gecko don't always expose them in the a11y tree to improve performance/minimise tree complexity.

Edit: Chrome always exposes generics in the internal a11y tree, but marks them as ignored, so they're effectively not exposed to platform APIs. Firefox doesn't have a concept of ignored; it just doesn't include them in the tree at all in some cases.

[stevefaulkner]

@jcsteh wrote:

Gecko doesn't expose them with a generic role if there's no tabindex, aria-label, etc. They don't exist in the a11y tree at all, more like role="none".

no role works for me

[MarioBatusic]

Is there any real use for the rowgroup role for the assistive technologies? I found it ever only a required grouping structure without any usefulness for AT.

[jnurthen]

The only usefulness I have found is to allow you specify a grouping as uninteresting when the browser would otherwise try to expose it as a generic breaking the table structure.
This is particularly true for FF where something gets exposed in the a11y tree for scrollable tables - setting this node to rowgroup is the only hack I can find to make these situations work without breaking the table structure. (the default exposed generic plays havoc with the a11y tree)

[cookiecrook]

@stevefaulkner wrote:

@jcsteh that makes sense, @cookiecrook @aleventhal does this sound reasonable?

I'll update the test and find out what Chromium and WebKit do with those.

@jnurthen wrote:

The only usefulness I have found is to allow you specify a grouping as uninteresting when the browser would otherwise try to expose it as a generic breaking the table structure.

I think the same would be true whether you used role=none or role=rowgroup [Update: fixed typo role=tbody]

[cookiecrook]

I get different results on Chrome running locally ("rowgroup" w/ or w/o the tabindex) than in Chrome on the WPT CI servers ("none" w/o tabindex, and "rowgroup" w/tabindex). @aleventhal any chance that's a recent change in Chromium?

WebKit returns no role ("") in both circumstances on current STP.

[jnurthen]

I think the same would be true whether you used role=none or role=tbody

As the element is automatically made focusable in FF you can't use role=none as it is ignored - and role=tbody doesn't exist.

[cookiecrook]

role=tbody was a typo. I meant role=rowgroup... I was saying that (focusability aside) both role=rowgroup (on thead/tbody/tfoot) and role=none result in them being ignored and therefore identical in the platform tree, in both WebKit and Chrome.

Of note: My local tests indicate a recent Chrome update vends the expected "rowgroup" role to computedrole, even though it's not mapped at the platform level.

[cookiecrook]

In the ARIA call, @jnurthen mentioned another test case with a focusable/scrollable tbody.

[benbeaudry]

Aaron made this change recently: https://chromium-review.googlesource.com/c/chromium/src/+/4072245. It appears to have
some changes around the growgroup role in Chromium. Might not be related but might also explains the recent changes
you're seeing in the latest Chrome version.

Edit: I finished reading through this commit and no, it doesn't appear to be changing anything about the rowgroup.

[aleventhal]

Chrome does basically the same as Firefox.

Internally, the rowgroup object actually always gets created but is ignored and not exposed in the platform tree unless necessary (needs to be an event target e.g. for focus, or has additional important properties like aria-label).

[aleventhal]

@jcsteh do you think there is any potential regression in AT behavior if we just expose them all? Do you have a preference?

Otherwise, it's probably only 1-2 hours to update Chrome's implementation and tests, so I'm fine making the change if that's what everyone decides. I'd probably be swayed by one of Jamie's arguments.

[cookiecrook]

…but there is a recent change to the results for this test in WPT.fyi (Canary?) compared to my local Chrome (stable 112…). 112 exposes rowgroup role to computedrole, but not in whatever build is in WPT.fyi CI

[aleventhal]

Sounds like a regression that needs a new issue filed at crbug.com then.

[cookiecrook]

I'm not comfortable filing a bug that Chromium is "wrong" given that we don't yet have consensus on what the behavior should be.

[scottaohara]

fwiw, i tend to agree that if the elements are not provided attributes important to accessibility (name, tabindex, etc.) then we could update the spec to indicate the element is not mapped. but if these attributes are provided , then presently rowgroup seems the best role we have to map to. i'm not seeing a downside to that at this time.

[jnurthen]

discussed at https://www.w3.org/2023/05/11-aria-minutes#t05

[jcsteh]

We recently had a bug filed against Firefox that made me realise there might be a semantic value to rowgroup for HTML tables: scope="rowgroup". Firefox doesn't currently support that, but if it did, it would need to know which rows were in the same group.

[scottaohara]

could that attribute also provide the signal to expose the rowgroup role?

so essentially if the tbody/foot/head is named, made focusable, or given other table attributes such as scope, that would mean the element needs to be exposed to the accessibility tree - then map to rowgroup. and otherwise, it can be treated as ignored or generic?

[cookiecrook]

Sounds reasonable, but we'll still need to make sure there isn't significant downstream impact to AT.

Update: However, if there is impact, I expect WebKit will be able to do what Chrome is currently doing: returning the rowgroup role in WebDriver even though it's not exposing it to the platform API. There is limited utility to that, but at least it would still confirm interoperability up to the point where the browsers vend the element to the system accessibility tree.

[jcsteh]

The problem is that the scope attribute is on descendants, not on the rowgroup. That means we have to make decisions about whether to put the rowgroup in the tree by either scanning all descendants first or by adjusting the ancestry when we hit a descendant with scope. In addition, if a new cell gets added with a scope, we'd have to adjust the ancestry or potentially rebuild the tree. That's all possible, but super complicated and error prone.

[scottaohara]

ah yes, sorry @jcsteh i misremembered that. that is a bit odd, hmm...

[jcsteh]

If I understand correctly, there seems to be agreement that at the very least, we should expose these as rowgroup if focusable, named, etc. For the purposes of WPT/Interop 2024, is it reasonable at this point to change the rowgroup tests in html-aam/table-roles.html so that the elements are focusable or labelled to avoid the remaining open question here? Or should we make those tests tentative until we get this resolved in the spec?