Bug: in Browse mode, clicking on the label of checkbox, NVDA is announcing inverted values of checkbox.

[franzitaz]

Steps to reproduce:

1. Open NVDA, version 2023.3
2. Open this link to test: NVDA testing input checkbox + label

Actual behavior:

In Browse mode, NVDA announces the wrong value of checkbox:
If I click on the label to check the checkbox, visually is checked, but NVDA announces that checkbox is not checked.
If I click again on the label to uncheck the checkbox, visually is unchecked, but NVDA announces that checkbox is checked.

Tested in these Browsers version:
Chrome Browser, version 119.0.6045.200, 64 bits.
Edge Browser, version 119.0.2151.97, 64 bits.
Firefox Browser, version 120.0, 64-bits.

Expected behavior:

The expected is:
If I click on the label to check the checkbox, NVDA needs to announce that checkbox is checked. And if I click on the label to uncheck the checkbox, NVDA needs to announce that checkbox is not checked.

System configuration

NVDA installed/portable/running from source:

Installed

---

NVDA version:

2023.3

---

Windows version:

Version 10.0.19045 Compilation 19045

---

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, I didn't find on NVDA website a previous version to test.

---

Screenshots:

[lukaszgo1]

Please mention in which web browsers (mentioning exact version numbers) this can be reproduced.

[Adriani90]

I think this is only reproducible in Chrome and Edge, because in Firefox NVDA does not announce the change of the state of the checkboxes at all in focus mode or when using the mouse.
@jcsteh what is the reason for Firefox not anouncing the state change at all?

Using the "before" or "after" atribute seems to lead to failure of success criterion 1.3.1 in WCAG:
https://www.w3.org/TR/WCAG20-TECHS/F87.html

I think supporting this correctly needs changes on both, screenreader and browsers side.
I personally would like to have consistent support for this because it could help in dynamic situations such as video conferencing where an event could be announced when focusing a name (e.g. "name" is speaking, where "is speaking" is inserted via the after atribute).

[jcsteh]

Is this failing in browse mode, focus mode or both?

In Firefox, the check box does get reported for me when I mouse click the label. I do intermittently see the state reported incorrectly, but the presence of ::before doesn't seem to make a difference.

My guess is that this has to do with the order of events being fired, since clicking the check box might focus it and then change its value or it might happen the other way around. Even so, NVDA should be reporting the change even if it does so afterward and it isn't. I'm not sure why.

[jcsteh]

I can only reproduce this in browse mode. In focus mode, this works as expected for me. That suggests the virtual buffer isn't being updated in time, maybe because the state change event is firing after the focus event.

[Adriani90]

I can only reproduce this in browse mode. In focus mode, this works as expected for me.

I see, I can reproduce this only sometimes though. And sometimes it works correctly both in focus and browse mode.

by the way, the only case where I can reproduce an inverted reporting of label and control state is when using the mouse and clicking on the label directly vs. using the mouse and clicking on the control which is at the left part of its label. This happens on both checkboxes.

[Adriani90]

Hmm this clicking on the label vs. clicking on the control itself behavior is quite weird. It seems when clicking on the control itself, the state is always reported correctly, double checked when pressing arrow keys in browse mode after changing the state with the mouse.
However, when clicking on the label, NVDA reports the previous state and not the current one. NVDA says for example
"normal checkbox not checked" although this was the state before I clicked on the label.

This seems quite severe.
@LeonarddeR is this maybe a regression introduced by #15518?

[Adriani90]

@franzitaz next time please include the expected reporting and the actual reporting as plain text and not only as screenshots. Here are a lot of blind developers and users like me for example and we cannot get the screenshots read by the screen reader. This caused some confusions on my side when testing.

[franzitaz]

@franzitaz next time please include the expected reporting and the actual reporting as plain text and not only as screenshots. Here are a lot of blind developers and users like me for example and we cannot get the screenshots read by the screen reader. This caused some confusions on my side when testing.

Thank you very much for your feedback @Adriani90 !
I updated my report.

Sorry, I am new on web accessibility, but I am studying to improve as a developer in web accessibility.
Thank you everyone!