I think there should be a toggle, as raised in #7756 (comment) and below.

Perhaps an option: "Update braille with live messages: ". With 3 options: off (default), all (polite), high priority (assertive).

I think a feature flag is a good idea, as assertive might be a sensible default at some point

@seanbudd I agree that a toggle may be a good idea, but right now NVDA doesn't offer that level of granularity for speech. We can disable the announcement of polite updates by turning off the reporting of dynamic changes, but there is no way to ignore aria-live ="assertive" even for speech. This PR extends the Braille support that already exist for all other live updates. If I want Braille to ignore aria-live updates, I just need to disable Braille messages like I would for UIA based notifications, for example. what about adding this basic level of support now, and work on a more comprehensive filter of aria-live updates that encompasses speech and Braille for 2024.1? this PR resolves the biggest shortcoming that exists right now for me in terms of Braille support in NVDA.

We wish to improve aria live polite behaviour as discussed in #13915.
This would mean that polite notifications are only announced after NVDA is idle (finished with speech).
I think if we are to accept this PR, this behaviour should match speech and polite live regions should not update braille.

Polite behaviour for braille which matches #13915 could be configured via an idle timeout setting, e.g. after braille hasn't been updated for 30sec, update the display with the polite notification.

Proposed ideal options when considering #13915

• "Interrupt speech with live messages: " - With 2 options: allow interrupt (default) and always wait until idle
• "Announce speech after idle (ms)" - Create option "NVDA is considered idle after X ms", low priority speech is announced after idle. #13915
• "Refresh braille automatically with live messages: ". With 3 options: allow interrupt (default), always wait until idle and never
• "Update braille display after idle (ms) "

I think I would change the report dynamic content changes option to a four state option. Both speech and braille, braille, speech and off.

I think I would change the report dynamic content changes option to a four state option.

@LeonarddeR I agree (and actually thought of this), but that's a config spec breaking change that I'd prefer to save for a larger ARIA refactor (especially if one is planned).

@seanbudd suppression of live regions in Braille is inconsistent with the user experience of many other popular screen readers, such as VoiceOver on iOS/MacOS. Additionally, live regions are currently completely inaccessible to deafblind users or those who otherwise use NVDA only via Braille, as indicated in #7756 (comment). As @rperez030 suggests, we shouldn't let the perfect be the enemy of the good: merging this pR now makes this information accessible in Braille, and we can always refine the experience later.

Similar to HID Braille support, I'll put this behind a feature flag (enabled by default, but can be disabled if problematic) for now. As a longer term plan, this flag should be removed and merged into "report dynamic content changes" during a config spec upgrade.

• PASS: Translation comments check.
• PASS: Unit tests.
• FAIL: Lint check. See test results for more information.
• PASS: System tests (tags: installer NVDA).
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/5w1oaej6vx9y6y8u/artifacts/output/nvda_snapshot_pr15078-28545,e793d659.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 0.9,
  INSTALL_END 0.9,
  BUILD_START 0.0,
  BUILD_END 24.0,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 21.7,
  FINISH_END 0.1

See test results for failed build of commit e793d65988

I think I would change the report dynamic content changes option to a four state option.

@LeonarddeR I agree (and actually thought of this), but that's a config spec breaking change that I'd prefer to save for a larger ARIA refactor (especially if one is planned).

I guess that's a product decision that is best to be taken by NV Access. I think this pr is too late for 2023.2. Personally I'd rather have the config change all settled instead of introducing a feature flag and then removing that in a follow up.

What if ARIA live regions would be inaccessible with speech, and there would be pr solving this. Should it be merged or not?

What if ARIA live regions would be inaccessible with speech, and there would be pr solving this. Should it be merged or not?

That is a great question. That is an example I often use when discussing accessibility issues related to visual content not being accessible to screen reader users. For someone that doesn't use Braille, or is a very ocasional user, this may feel secundary. For someone that depends primarily on Braille output, this is a limitation that should have been fixed years ago.

This new config setting seems appropriate - but can it be moved out of advanced settings into general braille settings?

The placement in advanced is because this feels more like a feature flag to me (something someone might disable in case of issues) rather than a user-facing setting. From the user perspective, you can disable Braille messages which will block both live region updates and any other flash messages that might be similarly disruptive.

Is there an official way of testing this for braille displays? The reason why I ask is because I am not getting incoming chat alerts for either Zoom or Teams (desktop apps), but they are voiced without issue. The same goes for mute/unmute notifications in Zoom, but I am unsure if they are specifically outputted via live regions or not.

Update: With a portable copy of NVDA, live regions are brailled, but not with my installed copy. I even restarted with add-ons disabled and no difference. In NVDA.ini, reportLiveRegions is set to DEFAULT. And yes, I even uninstalled and reinstalled NVDA. Log fragment below:

IO - speech.speech.speak (10:53:48.608) - MainThread (4836):
Speaking ['Static Content The changing content will take place below.  Modified Content #1   ']
IO - braille.BrailleBuffer.update (10:53:48.720) - MainThread (4836):
Braille regions text: ['btn Submit btn Clear added content btn Stop adding content ']
IO - braille.BrailleHandler.update (10:53:48.720) - MainThread (4836):
Braille window dots: 12 2345 1345 - 6 234 136 12 134 24 2345 - 12 2345 1345 - 6 14 123 15 345 - 1 256 1246 - 25 2345 26 2345 - 12 2345 1345 - 6 34 135 1234 -