Search fields: announce suggestion count

[josephsl]

Steps to reproduce:

A list of the steps you take to demonstrate the problem.

Example:

1. Open Chrome
2. Browse to www.google.com
3. Type "Hello"
4. Notice an error sound when enter is pressed.

Please also remember to attach a zip of any files required to reproduce the issue.

Expected behavior:

Tell us what should happen.

Actual behavior:

Tell us what happens instead.

System configuration:

NVDA version:

Example: next-14027,c80e529f

NVDA Installed or portable:

Other information:

Example: Running in a VM

Windows version:

Example: Windows 10 Version 1607 Build 14393.1066

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

Other questions:

Does the issue still occur after restarting your PC?

Have you tried any other versions of NVDA?

Please list them and the result Hi,

Building on #6241: in some cases (such as search box in Settings app in Windows 10), it is possible to know how many suggestions are there. Thus allow NVDA to announce suggestion count.

One big question: should this be tied to position info setting or create a new setting for this? I'm leaning towards former.

Technical: because controllerFor returns a list of objects and because the first object is a list, it is possible to use list.childCount. In other words, this is yet another Windows 10 App Essentials code being donated to NV Access.

Thanks.

[jcsteh]

While this is certainly possible, we should consider use cases and possible disadvantages. Why is this information actually useful before the user has chosen to interact with suggestions? One of the advantages of using a sound to indicate suggestions appearing is that it is less distracting and doesn't take the user's attention, while still indicating the fact for those who want to know. It also isn't interrupted by typing. In contrast, adding an announcement like this rather defeats the point of the audio indicator. Note that the user will still get the number of suggestions when they start moving through them. So, getting this information if they do want it is just one keystroke away. Can you think of any reasons this is necessary in addition to the indicator?

[josephsl]

Hi, one possible use case is when searching for content on Windows Store where the user may not know how many search results are available. Thanks.

From: James Teh [mailto:notifications@github.com] Sent: Tuesday, June 27, 2017 7:24 PM To: nvaccess/nvda nvda@noreply.github.com Cc: Joseph Lee joseph.lee22590@gmail.com; Author author@noreply.github.com Subject: Re: [nvaccess/nvda] Search fields: announce suggestion count (#7330)

While this is certainly possible, we should consider use cases and possible disadvantages. Why is this information actually useful before the user has chosen to interact with suggestions? One of the advantages of using a sound to indicate suggestions appearing is that it is less distracting and doesn't take the user's attention, while still indicating the fact for those who want to know. It also isn't interrupted by typing. In contrast, adding an announcement like this rather defeats the point of the audio indicator. Note that the user will still get the number of suggestions when they start moving through them. So, getting this information if they do want it is just one keystroke away. Can you think of any reasons this is necessary in addition to the indicator?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/7330#issuecomment-311538767 , or mute the thread https://github.com/notifications/unsubscribe-auth/AHgLkILnjqsRGoKH8QjOUFJtZxUlUbC5ks5sIblPgaJpZM4OHXzW .

[jcsteh]

They would get that as soon as they hit down arrow, though. Even if this use case were super important, that suggests we should drop the audio indicator and just report the suggestion count. Having both is surely redundant. Personally, I'd opt for not having the count.

@MichaelDCurran, @QChristensen, thoughts?

[Qchristensen]

I agree with Jamie that reading the number of results while typing is distracting, and the information is readily available by down arrowing. I started wondering if we could play say a high pitched tone when suggestions first appear and get lower as they narrow down. The problem with that idea is that unlike say progress bars, which have defined start and end points, who is to say how many search results might be the upper limit?

So then I thought, what if we play a tone, like now when the search suggestions first appear, and a lower tone when the number of suggestions drops below say 10. It's not too many to arrow through, but getting small enough that it should have what you want without you needing to type the whole thing. Some places have set upper limits of how many they will show (Chrome shows up to 6, Firefox and Edge 10, Windows Store 11). I wonder if fields disclose their maximum results? In those cases, max - 1 might be more useful than an arbitrary number?

Otherwise, I was wondering whether a command like NVDA+numpad delete / NVDA+delete could be used to give the exact count? That would avoid the user needing to down arrow. Down arrow is definitely the easiest way to get an exact count, but there are places, such as the address bar in Chrome or Firefox, where using the down arrow will move through the suggestions and change the original text, so you can't keep typing where you left off if what you want isn't yet among the suggestions.

[derekriemer]

We could do like indentone does, stop the sound at say 3 octaves above max, where one note is one suggestion item, but I don't really know this seems distracting.

On Tue, Jun 27, 2017 at 9:44 PM, Quentin Christensen < notifications@github.com> wrote:

I agree with Jamie that reading the number of results while typing is distracting, and the information is readily available by down arrowing. I started wondering if we could play say a high pitched tone when suggestions first appear and get lower as they narrow down. The problem with that idea is that unlike say progress bars, which have defined start and end points, who is to say how many search results might be the upper limit?

So then I thought, what if we play a tone, like now when the search suggestions first appear, and a lower tone when the number of suggestions drops below say 10. It's not too many to arrow through, but getting small enough that it should have what you want without you needing to type the whole thing. Some places have set upper limits of how many they will show (Chrome shows up to 6, Firefox and Edge 10, Windows Store 11). I wonder if fields disclose their maximum results? In those cases, max - 1 might be more useful than an arbitrary number?

Otherwise, I was wondering whether a command like NVDA+numpad delete / NVDA+delete could be used to give the exact count? That would avoid the user needing to down arrow. Down arrow is definitely the easiest way to get an exact count, but there are places, such as the address bar in Chrome or Firefox, where using the down arrow will move through the suggestions and change the original text, so you can't keep typing where you left off if what you want isn't yet among the suggestions.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/7330#issuecomment-311548631, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivTC6LHU97EeRjDpAlah7oL6UuM7Fks5sIcwJgaJpZM4OHXzW .

--

Derek Riemer: Improving the world one byte at a time!

• University of Colorado Boulder Department of computer science, 4th year undergraduate student.
• Accessibility enthusiast.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Skier.

Personal website http://derekriemer.com

[jcsteh]

1. In Chrome/Firefox, you can press escape to dismiss the autocomplete, at which point what you originally typed will be restored.
2. This suggestions code actually doesn't apply in Firefox/Chrome anyway, only in Windows autocomplete controls (like the Start Menu, Settings Search, etc.). However, that's not necessarily going to be the case forever, even though it's the state of things now.
3. I kinda like the idea of having the report location command provide this info, though it doesn't quite "fit" the idea of "location". Report focus might be a better fit, but there's no way currently to provide arbitrary info with that command.

[derekriemer]

@jcsteh commented on Jun 28, 2017, 8:07 PM MDT:

3. I kinda like the idea of having the report location command provide this info, though it doesn't quite "fit" the idea of "location". Report focus might be a better fit, but there's no way currently to provide arbitrary info with that command.

Isn't that what overriding reportFocus does?

[jcsteh]

Nope. reportFocus is used by focus events, not by NVDA+tab.

[Qchristensen]

Re this code not being used in Chrome / Firefox, would adding extra functionality to some autocomplete fields (Start menu search etc) but not others then cause confusion. As hard as it is with every single program feeling the need to re-invent every type of control, as a user, I get used to the way a particular type of control works (announcing number of suggestions, or not, for instance), and then I ideally like all controls that do the same thing to work the same.

[jcsteh]

There are limits to how much we can unify this due to the severely differing implementations. Also, those controls already behave rather differently; I imagine that's true to some extent even for sighted users?

[derekriemer]

@jcsteh commented on Jul 1, 2017, 5:24 AM MDT:

Nope. reportFocus is used by focus events, not by NVDA+tab.

My latex-access code uses reportFocus in this way, and gets called.

[derekriemer]

never mind, I have a script_reportFocus I forgot about there which calls reportFocus for nvda+tab.

[josephsl]

Hi,

August 2021 update: the implementation is being tested. Turns out the overall mechanism comes from UIA layout invalidated event, which is quite separate from UIA controller for/suggestions event.

To (finally) answer Quentin's question and to provide an update for Jamie: as I hinted earlier, Windows 10/11 Start menu implementation is part of NVDA, and a related concept was merged into NVDA 2021.2 (to deal with Windows Search found in File Explorer since Windows 10 Version 1909). The current implementation (suggestion sound and auto-suggest announcement) is possible in Start menu because NVDA will automatically announce the first result. For ones coded with layout invalidated event (because that's the other auto-suggest implementation that is under discussion here), suggestion sound is played but no suggestion count is announced, and that's the crux of #12758. I think, for consistency and to provide better experience, I vote to implement this issue, whjich involves donating parts of Windows App Essentials code to NVDA Core.

Looks like a more generic issue might be in order (to mention layout invalidated event)...

Thanks.