NVDA fails to read aria-labeledby label associated with a radio group in browse mode

[PratikP1]

When using "f" or "r" keys to find radio buttons on a page while in browse mode, NVDA does not read the associated label. At this time I can't say whether this is limited to labels associated by aria-labeledby and other techniques. My current testing example is only with aria-labeledby. My recollection is that all labels are not read. This occurs in all browsers. Tested with IE 11, FF 52, Edge on insider build 15058 and Chrome Canary.

• Actual behavior: the label is only read with focus mode enabled.
• Expected behavior: label should be read the first time the user encounters the radio group similar to what occurs in focus mode.

STR:

1. Open FF.
2. press alt+d to go to the addressbar.
3. Visit the following link: https://ibma.github.io/Va11yS/ARIA/ARIA2_example3.html
4. Navigate to the radio group by repeatedly pressing "f" or pressing "r."

[jcsteh]

Reading group labels when moving the browse mode cursor would result in duplication, since the group label is usually visible. Of course, you end up skipping the label when you use quick navigation, so we'd have to find some way of differentiating these cases. That said, we get enough complaints as it is that we sometimes read other elements such as landmarks, tables, etc. before the element itself when using quick navigation. I'm concerned we'd end up with similar complaints here. While it obviously makes sense to read the group names when tabbing, using quick navigation normally suggests you know what you're looking for. Why do you feel this is different to landmarks, etc.?

[PratikP1]

I understand the concern. The difference here is that the label is required for successful form interaction—the primary function one might say. If the capability of interacting with a radio button in the browse mode is possible, then all necessary information to conduct such interaction must be made available. Otherwise, that interaction is only made half possible.

[jcsteh]

I take your point, but it's worth noting two things:

1. It is still possible to access the relevant information; you may just need to review a line or two above to get context. That is not unusual when using quick navigation, even for links, list items, etc.
2. There may be other information required for successful interaction; e.g. descriptive text. There are always going to be cases where one needs to review for context when using quick navigation.

See also #3321. That one is related to tabbing, not quick navigation, but they are handled similarly as far as NVDA is concerned. I think we could address both with the same fix, assuming we can figure out what that fix is.

P2 because I guess users might try this without thinking to check context and miss important info, and #3321 is p2 anyway.

[fernando-jose-silva]

good evening.
If I may be allowed a user opinion in this case.
I would vote for when navigating with the arrows by the pages when arriving in a text field or other controls the nvda is spoken the name of the control, without that I have to see the answer.
I as a user without even a programming knowledge I once reported to a website developer that this was a site problem because I thought the site had no description for the object name, in the case a text field.
Other readers pronounce the name of the object by hoaxing it with the arrows, and I got confused a little to understand that nvda does not fix it, and even before reading this call I thought it was a problem in nvda, I discovered that it is a characteristic now.

In the end an account only to substantiate my vote.

Thanks for the wonderful development of nvda, every day that passes I am more enthusiastic about your project.

[PratikP1]

Update: the URL I referenced in my steps has been updated to https://ibma.github.io/Va11yS/WCAG_ARIA/ARIA2_example3.html