Optionally report groupings (e.g. aria role group) in browse mode

[LeonarddeR]

Is your feature request related to a problem? Please describe.

Open the following on the Firefox or Chrome address bar:

data:text/html, <p><button>Button in paragraph</button></p><p role="group" aria-label="This is a group"><button>Button in group</button></p>

Neither the aria role of group, nor the group label are provided in browse mode. With focus mode, when you tab through the buttons, NVDA announces when you enter the grouping along with its label.

Note that HTML tag <figure> is also mapped to IA2_ROLE_GROUPING. JAWS reports this role as figure. As Firefox and Chrome map figure to grouping, the same issue as described above applies here.

Describe the solution you'd like

I think that at least figures should be reported in browse mode, preferably as figure instead of grouping. Also, I think that in more cases, it can be beneficial to have groupings reported as such.

cc @dkager

[bramd]

@LeonarddeR This is the same case as fieldset+legend, now there is no indication of the legend's role in browse mode. Do you know how other screen readers handle this case?

Not the same as this issue, but related:
If we announce more things as groups/containers I'm worried more and more how NVDA speaks them. It now is already very verbose if you enter a landmark or region with an accessible name (e.g. aria-label). Frustrating if you just want to hear the content at the start of the group.

[LeonarddeR]

@jcsteh: Could you please share your thoughts about this?

[jcsteh]

I've always found this pretty tricky/controversial.

There are certainly cases (like this one) where information can be missed if we don't report this. On the other hand, it can also cause double reporting. A lot of the time (particularly with fieldset/legend), the legend is visible (perhaps even semantically identified as a heading), so the user will see that first as they browse the document. In that case, reading the group label is redundant. (The reason this isn't a consideration in focus mode is that labels aren't normally navigable in focus mode, so double reporting of this type is rare.)

One possibility is that we could avoid reporting groups (or just their labels?) in browse mode if the label is visible, since it's likely that the user would already have seen it in this case. That could result in confusion in some cases, though; I can already hear questions/complaints like "why doesn't NVDA report group x but it does group y". People might not understand the reason for the inconsistency. Still, we do this for some controls already, so there is precedent.

[dkager]

Very interesting discussion. Should groups/fieldsets also be escapable, e.g. with comma in browse mode? I'm thinking this would be particularly useful for figures, but might clutter things if you have a list in a fieldset in a form in a landmark. Which ones do you expect to be able to escape from?

[JulienCochuyt]

One possibility is that we could avoid reporting groups (or just their labels?) in browse mode if the label is visible, since it's likely that the user would already have seen it in this case.

+1
I really think, despite the need to re-teach the reason for this behavior from time to time in bug reports, that this would be the ideal behavior.

Which ones do you expect to be able to escape from?

I would naively say "each of them, one by one".
I am in favor of being able to escape with comma as much containers as possible, even if it means to sometimes hit comma a few times to reach the end of an outer container.

[LeonarddeR]

@MarcoZehe I actually came up with this issue because of role="figure". Do you think #10083 can be treated as a duplicate of this issue?

[LeonarddeR]

I don't know exactly why this is, but NVDA already filters out the label on the grouping for a fieldset/legend combination. I think this is exactly how we want things to be.

[MarcoZehe]

@MarcoZehe I actually came up with this issue because of role="figure". Do you think #10083 can be treated as a duplicate of this issue?

Yes, definitely. If Github had given me this as a duplicate suggestion, which it didn't, I would have commented here right away with my use case. :)