Should role="group" sometimes map like it's a <fieldset>?

[aleventhal]

From my memory, the original intention of role=group when it was added back pre-ARIA 1.0, was to act the same as an HTML <fieldset>.

It is treated it that way on Windows at least, where a ROLE_SYSTEM_GROUPING is the mapping for either one.

However, as @jnurthen pointed out, the treatment by the screen reader, and perhaps the mapping, depends on where it is used doesn’t it. For example, in a tree, menu or listbox you probably wouldn’t want it expressed like a fieldset.

There doesn't seem to be any other way to expose a fieldset-like element in ARIA.

Here's a Chrome bug where we are looking to get this answered:
https://bugs.chromium.org/p/chromium/issues/detail?id=577341

[cookiecrook]

Aaron and I both remember this coming up in another issue recently. Looping in @mcking65 in case recalls and he can find it faster than we can. I think it may have been on one of his edits.

[cookiecrook]

My recollection is that it would be fine to map it this way for direct child form elements but not for random nestings. IOW, a parent group would act like a fields, but a non-parent ancestor group would not. Or we should use a different role.

[aleventhal]

Or we could black list it in tree, menu, listbox.

[aleventhal]

Worth considering: may want to switch based on whether there is an accessible name. Not arguing for or against, just bringing it up.

[cookiecrook]

Prior context mentioned above was an ARIA-AT discussion @mcking65 and I had with @zcorpan and @isaacdurazo.

Some selections from the meeting notes:

ARIA groups surrounding checkboxes are currently required (by non-normative APG, not the normative ARIA spec?) to behave like fieldsets. James thinks this is problematic and could result in problems with verbosity. It makes sense to convey group boundaries, but not necessarily announcing all ancestor group names when navigating between elements, for example.

So… related to @aleventhal's comment about:

[we] may want to switch [the behavior of whether group applies like a fieldset] based on whether there is an accessible name.

Seems to me that the heuristic needs to be more complex. To beat up on Aaron's straw man, I could see it 1) causing related form elements to be labeled by an ancestor group that contains but is not related to the fields, or 2) causing unrelated form elements to become grouped by any shared ancestor that is a labeled group.

[cookiecrook]

Is there a reason we can't have a 1:1 mapping between <fieldset> and a new fieldset role that inherits from group? That'd be really clear for authors, and trivial to implement in browsers.

[cookiecrook]

Of note: Current VoiceOver/WebKit is resulting in the desired fieldset-like behavior in this ARIA-AT checkbox test example, so maybe we should start by determining where browsers/AT are inconsistent, and where there may be false positives (my hypothetical 1 and 2 above).