NVDA + Firefox does not read labels associated with radio button if radio buttons have position: absolute

[mermaid]

NVDA + Firefox does not read labels associated with radio button if radio buttons have position: absolute.
It seems to work correctly on Chrome & Edge when I tested it, Firefox was the only browser with this issue.

Steps to reproduce:

1. Run https://jsfiddle.net/nrzg52a8/ or index.html file uploaded to this ticket
2. use down arrows to move down the page, passed "hello" and onto the radio button

Actual behavior:

NVDA Speech: "radio button not checked"

Expected behavior:

NVDA Speech: "radio button not checked First Name" or something to that effect (label being read out)

System configuration

NVDA installed/portable/running from source:

installed

NVDA version:

release 2020.4

Windows version:

windows 10

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

Firefox 88 (also tested on 89 beta)

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.

also tested on 2020.2

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

Yes, no add ons are installed

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

Yes

html and log.zip

[Adriani90]

In Firefox the label is reported as if it was on the line below the radio button. In Chrome and Edge the radio button is spanned aroung the label, at least NVDA reports the beginning of the radio button when landing on "f" and the end of the radio button after the letter "e".

So it seems it is a different rendering and is more related to browsers than to NVDA.

@jcsteh should I open an issue on Bugzilla for this? Or is there already one?

Regarding user impact, I can imagine having the label reported when landing on the control is way better. In many forms i noticed the label is reported either above or below the control, sometimes it is both in the same form. So it is confusing when trying to fill a form and the label is not directly associated with the control.

[jcsteh]

This "works" in Chrome because Chrome removes the label element from the accessibility tree altogether. While this appears desirable, it causes some problems. For example:

data:text/html,<input type="radio" id="radio"><label for="radio" style="font-weight: bold;">hi

In Chrome, if you try to query the formatting (NVDA+f) for the text, you will get "No formatting information". In contrast, in Firefox, NVDA will tell you that the text is bold. This probably doesn't matter to users most of the time, but it could be relevant and thus Firefox doesn't strip the label.

Note that Chrome won't strip the label if there are any children other than text nodes. For example:

data:text/html,<input type="radio" id="radio"><label for="radio" style="position: absolute;"><span>hi

Here, you get the same result you see in Firefox. So, even though the original test case appears to work in Chrome, this isn't reliable/consistent as soon as you make the markup slightly more complicated.

As to why the radio button is rendered on a separate line in these cases, this occurs because the label becomes a block element when it is position: absolute and NVDA always renders block elements on separate lines in browse mode.

[Adriani90]

Thanks very much for this valuable explanation. I also think under these circumstances it might be better to be able to gather the formating information for a label, for example in some waird online games it might be requested to complete only a certain type of fields which are indicated by the formating of their label.
According to my test it seems NVDA can report the formating information in focus mode though. I don't know how ever which formating exactly, because in focus mode you cannot navigate the label character by character.

Jamie is it then possible for NVDA to display the label always on the line above the control in browse mode when screen layout is disabled in NVDA's settings?
On another note, it seems as of now enabling screen layout does not have any effect on how this is displayed in browse mode.

[jcsteh]

The page is structured such that the radio button comes before the label and the label is a block element. Block element means that it is rendered on a separate line. This is why the radio button appears first and why the label appears on a separate line even in screen layout.

All of this said, I do acknowledge that this isn't great for users. There might be some workaround where the buffer can choose to ignore the fact that the label is a block element if it appears directly after its target radio button or something like that. That seems fragile, but I guess it could work.