Narrator does not announce updated value of NumberBox when we change the value with increase/decrease button.

[YuliKl]

Describe the bug

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Turn on Narrator
2. Launch XAML Controls Gallery.
3. Activate NumberBox from "What's New" page.
4. Navigate to number box placed under header A number box with Spin button.
5. Ensure SpinButtonPlacement is set to Compact.
6. Now try to increase/decrease the value of number box by activating increase/decrease button only and observe if the updated value is announced to user.

Expected behavior

Narrator should announce updated value of number box.

Screenshots

Version Info

Xaml Controls Gallery version 1.2.12.0

NuGet package version:

Additional context

Feels related to #1879

Copied from internal bug

[marcelwgn]

It seems like that the issue is caused by the following line:

microsoft-ui-xaml/dev/NumberBox/NumberBox.cpp

Line 587 in 1a39aa7

textBox.Select(static_cast<int32_t>(newText.size()), 0);

One possible workaround (albeit not the perfect fix) is to select the complete text, that is change the line to:

textBox.Select(0, static_cast<int32_t>(newText.size())); 

which would result in the text being announced as "[value] selected" where value is the current value of the NumberBox, e.g. 12.

Would that be an acceptable fix?

[marcelwgn]

@ranjeshj @YuliKl @SavoySchuler Your thoughts?

[Felix-Dev]

@chingucoding As you said it wouldn't be a pefect fix. In fact I'm not sure if I'd be too much of a fan of this workaround, as it would constantly select/keep the NumberBox value selected when clicking the up/down buttons. I would like to have a experience where I can increase/decrease a value in larger steps and rapidly modify the last digit(s) if required. Granted, with the value selected this would just be one more click more...but it is one additional click. Furthermore, this would impact every user in their NumberBox experience, even if not by much, no matter if they use the Narrator or not.

Is there no other way to to announce the updated value in Narrator?

[marcelwgn]

The fix I mentioned earlier in this thread wouldn't change that behavior. We are already changing the caret everytime we change the value. What my change would do is just change HOW we change the caret. Currrently iirc we set the caret at the end of the number when the value changes. For some reason Narrator doesn't deal with that that well, however if we select the text, that Narrator would announce the new value.

[Felix-Dev]

@chingucoding As you said correctly, currently using the up and down spin buttons, we set the caret to the end of the of value while not selecting the value. That way, I can easily press backspace keybord key and modify the last digit if required (in case the increase/decrease steps used are larger than "1"). With your proposed workaround, that wouldn't be possible any longer. Each time I press the up/down spin buttons, the value would be selected no matter what. So instead of just having to press backspace key, I now need to press an additional key first to unselect the value. This is the change in behavior I referred to in the post above which would affect the UX of everyone using the NumberBox - no matter if they use narrator or not.

[marcelwgn]

Oh sorry totally missread your comment. My apologizes.

The problem I see is the following: When we change the value through the decrease/increase buttons, we raise the ValuChanged event on the NumberBoxAutomationPeer. However Narrator seems to ignore that. Instead of announcing "[value] updated" or something like that, it just announces "end of line" as we are also setting the caret to the end of line. It doesn't matter whether we raise the ValueChanged UIA event before or after we change the caret position.

Through the "hack" proposed above, essentially we would get the narrator to announce the not announce "end of line" but rather the value.

[Felix-Dev]

Yeah, "end of line" is not acceptable. Huh...I really do hope there's a better way here to fix this issue.

[marcelwgn]

Yes I hope so too, but narrator seems a bit "picky" given that #2692 also is currently paused as narrator doesn't seem to care about a selection change either. Interestingly, some properties work just fine while others don't for some reason.

[ranjeshj]

Are you saying that changing the value and raising value changed automation event is somehow making Narrator read the wrong value ? I would have expected Narrator to get the new value through the automation peer and announce that. Is "end of line" coming from the TextBox's automation peer ?

[marcelwgn]

It seems that changing the caret position happens directly after we raise ValueChanged resulting in narrator skipping announcing the new value and jumps to announcing "end of line".

Unfortunately, raising "ValueChanged" after we set the caret also doesn't seem to work here for some reason.

[ranjeshj]

This is likely an issue with how Narrator is reacting to value changes. This is tracked by an internal bug (listed in the issue description above).

[karkarl]

Does not repro (updated values are read properly by narrator) so closing.