NVDA + Firefox does not read labels associated with radio button if radio button is wrapped in a div element

[teodorachiosa]

Steps to reproduce:

• Open Firefox
• Open this link: Codepen link. In the Codepen link you can find an example in which a radio input is properly linked to a label via "id" and "for" attributes and the input is wrapped in a div element (for UI customization purposes).

Actual behavior:

When navigating with the arrow keys in order to read the radio, the label is read separately from the input. In the NVDA Speech Viewer we can see the following output, on 2 separate lines:

• radio button not checked
• clickable Label for radio goes here

Expected behavior:

The radio button and its label should be read together. If we use a span element instead of a div element, we get the desired behavior: Codepen link with expected behavior.

Expected NVDA Speech Viewer output:

• radio button checked clickable Label for radio goes here

NVDA logs, crash dumps and other attachments:

Skipped, due to the issue being easy to reproduce in Codepen.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

release 2022.2

Windows version:

Windows 10 Version 10.0.19044 Build 19044

Name and version of other software in use when reproducing the issue:

Firefox version 103.0.2 (64-bit)

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes.

Have you tried any other versions of NVDA? If so, please report their behaviors.

No.

If NVDA add-ons are disabled, is your problem still occurring?

No addons.

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Yes

[seanbudd]

Speech viewer is a developer tool, and does not perfectly match up to speech which is provided to the user. Is there an issue with how the speech is announced for the element? Can you please describe why this is a problem?

[seanbudd]

Closing as invalid until more information is provided

[teodorachiosa]

Speech viewer is a developer tool, and does not perfectly match up to speech which is provided to the user. Is there an issue with how the speech is announced for the element? Can you please describe why this is a problem?

What I've described above happens in both Speech Viewer and also with regular use (listening to NVDA). The radio itself is announced separately from its label. The user needs to do an extra step (one more down arrow press) to hear the radio label. I provided reproduction links so that you guys can check the issue for yourselves. Did you check it?

Still reproducing in version 2022.2.2.

[Adriani90]

In Crome it seems to work as expected.

cc: @jcsteh regarding firefox.

[jcsteh]

The difference is because Chrome strips the label element out of the accessibility tree altogether. While this has the desired effect in this case, it also means the user can't see any of the formatting information in the label (only the plain text), which might be a problem in other cases.

[Adriani90]

Thanks for the info. I've compared Chrome and firefox and can confirm what you say, formating information cannot be retrieved in Chrome. From an user perspective, I think the behavior in Firefox has more advantages, and in the end when I press r in browse mode, in either of these browsers, the label and the control are being reported all together as expected. I tend to close this issue for now. it will need an external change from Chrome and/or firefox to match the behavior in both browsers. Actually when I move the mouse, the label of the control is situated right below the control itself, at least that s NVDA reporting.