Respect aria live politeness for UIA objects

[LeonarddeR]

Link to issue number:

Related to ##9079

Summary of the issue:

Visual Studio uses a live region to communicate relevant things to the screen reader. However, in the case of intellisense, the selected item is spoken after the current line of text, which is very annoying when working with long lines.

Description of how this pull request fixes the issue:

We actually never supported the aria live politeness setting for UIA objects. I implemented the following:

1. A new enumeration in the aria module for the three politeness settings (off, polite, assertive)
2. A new object property liveRegionPoliteness that should return one of these enum values. This defaults to off and is implemented for UIA, IA2Web and MSHTML. For the latter two, it's currently doing nothing, it's only implemented for reference and consistency.
3. The live region changed event now uses speech priority based on politeness. Even when politeness is assertive, priority is NEXT rather than Normal. This ensures that after a speech utterance is finished, it has higher priority than next utterances by default. It could be argued to leave default priority to Normal, though, but I'd say that this is where Next is meant for.

Testing performed:

Tested in Visual Studio that intellisense popups are spoken instantly.

Known issues with pull request:

In #9079, the aria live politeness level is regarded to as level, whereas I chose for politeness, in line with MDN. Should we be consistent here, and what is the preferred term?

Change log entry:

• Changes for developers
  • The aria live politeness setting for live regions can now be found on NVDA Objects using the liveRegionPoliteness property.

[michaelDCurran]

My reading of MDN / the spec leads me to believe that assertive should be mapped to a speech priority of next, and polite should be mapped to a speech priority of normal.
Note that in the original design of ARIA live regions back in 2007, there was the value: rude, which we would have mapped to a speech priority of now.
I do understand however, that mapping assertive to next would not specifically fix issue #8336 .
I'm trying to reproduce issue #8336 myself, but am having some trouble. All auto completes / suggestions I get when typing code in Visual Studio are menu items, and we do interrupt speech for each one. This is Visual Studio 2019 (16.7.3).

[LeonarddeR]

My reading of MDN / the spec leads me to believe that assertive should be mapped to a speech priority of next, and polite should be mapped to a speech priority of normal.

That makes sense. However I"m afraid that in practice, there's not much difference between how next and normal are reported. Only during say all, next will probably kick in quicker.

I do understand however, that mapping assertive to next would not specifically fix issue #8336 .

This is correct.

I'm trying to reproduce issue #8336 myself, but am having some trouble. All auto completes / suggestions I get when typing code in Visual Studio are menu items, and we do interrupt speech for each one. This is Visual Studio 2019 (16.7.3).

That is weird. What happens if you move with arrow keys through the suggestions? Do they speak instantly?
There are menu items indeed, but with a bare NVDA, they should speak using a live region instead.

[michaelDCurran]

I'm certainly getting speech interruption on each downArrow press. I'll try and investigate tomorrow where that is actually coming from.

[michaelDCurran]

On my machine at least, with VS 2019 16.7, the those menu items use the IntelliSenseItem UIA NVDAObject. And that is where the cancelSpeech etc is coming from.

[LeonarddeR]

This is strange. It seems like the logic that works for VS2017 also applies to VS2019 on your system.

here, on VS 2019, the class name of the list items is 'IntellisenseMenuItem' which is the same as in vs2017. However, here the automation id of the parent list is CompletionList, not listBoxCompletions as in VS2017.

What str are you following in Visual Studio? May be there's a difference in what code you're working with (e.g. i'm working with C# code here)

[LeonarddeR]

Ugh, I just tried it with C++ code, and yes, you're correct, there the class name of the list is different. How utterly confusing!

[LeonarddeR]

Based on the above comments, I decided to go with @michaelDCurran's suggestiong regarding speech priorities. Visual Studio issues have to be solved in a separate pr.

[manish10]

Hello,
I am not sure if I understand the discussion above completely, so, apologies fi I am asking something you already answered.
Does this change now fix #8336 or not?
If this or another change does fix that issue, is there a way I can test it and provide feedback? (this is probably a well documented process...if you can point me to it, I should be able to follow it)

[LeonarddeR]

Does this change now fix #8336 or not?

I'm afraid it does no longer. However, there is now a specific pr: #11609

[codeofdusk]

Has this PR been superseded by #11609?

[LeonarddeR]

No. We still don't respect Aria Live politeness for other live region controls until this pr is merged.