NVDA reads updated states of changed checkboxes/radio buttons... after changes to aria-live="polite" regions triggered by them

EricDunsworth commented 4 months ago

If a user changes the status of a checkbox or radio button associated to an ARIA live (aria-live="polite") region, NVDA currently reads the region's changed content prior to the updated state of the form control that triggered it.

That behaviour seems more in line with what I'd expect from aria-live="assertive" as opposed to aria-live="polite" (but shouldn't matter in practice until #6335 is resolved). It feels impolite not to be conveying the direct result of the user's action before reading the live region's changed content.

According to the ARIA 1.2 spec's explanation of the aria-live property, polite changes should be presented gracefully:

Indicates that updates to the region should be presented at the next graceful opportunity, such as at the end of speaking the current sentence or when the user pauses typing.

I was wondering if something could be done to announce state updates of checkboxes and radio buttons prior to changes to aria-live="polite" regions?

PS: I experienced this behaviour in NVDA via both Chrome and Firefox. Not sure how other assistive technologies (like JAWS or VoiceOver) handle this kind of scenario.

Steps to reproduce:

Visit this JS Bin sample in any browser
Tab to the "My checkbox" checkbox
Press the spacebar key to "tick" the checkbox
Press the spacebar key again to "untick" the checkbox
Tab to the "My radio button" radio button
Press the spacebar key to "tick" the radio button

Actual behavior (Firefox):

My checkbox  check box  not checked  
Changed  
checked
Initial  
not checked
My radio button  radio button  not checked
space
Changed  
checked

Expected behavior (Firefox):

My checkbox  check box  not checked  
checked
Changed  
not checked
Initial  
My radio button  radio button  not checked
space
checked
Changed

NVDA logs, crash dumps and other attachments:

N/A

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2024.2 (2024.2.0.32555)

Windows version:

10.0.19045 Build 19045 (22H2)

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

Firefox version: 127.0.2 (64-bit)
Firefox Developer Edition version: 128.0b9 (64-bit)
Chrome 126.0.6478.127 (Official Build) (64-bit)

Other information about your system:

N/A

Other questions

Does the issue still occur after restarting your computer?

Haven't tried

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?

Yes (using factory default configuration - doesn't come with any add-ons)

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

Haven't tried

Adriani90 commented 4 months ago

cc: @SaschaCowley, @jcsteh

jcsteh commented 4 months ago

I certainly understand why this makes sense from a user perspective. From an implementation perspective:

I'm not sure how this could be done without delaying all live region reports just in case there's some other event we might want to report first. That would make them less responsive in all cases, which doesn't seem ideal.
On the browser side, mutation events are always fired before other events like focus, state changes, etc. This is because other events are often dependent on the current tree structure and mutation events are a fundamental part of ensuring the tree structure is up to date.

Definitely an interesting conundrum.

nvaccess / nvda