GUI: Unable to jump to option in combo box by pressing multiple initial alphabets

[bhavyashah]

Steps to reproduce:

1 Open NVDA's Voice Settings dialog. 2 Tab to the Voice combo box. Assuming your selected speech synthesizer is ESpeak, this combo box displays a list of languages. If you are using another synth, the STR will vary but the nature of this bug will stay the same and should be replicable with slight changes to the steps. 3 Press 'h' followed by 'i' in quick succession.

Actual behavior:

Focus jumps to Hakka Chinese and then to Interlingua.

Expected behavior:

Focus should possibly jump to Hakka Chinese first but then immediately move to Hindi. This is because pressing 'i' immediately after 'h' indicates that I am looking for an option that starts with 'hi' as opposed to suggesting that I changed my mind from searching for a language starting with 'h' to a language starting with 'i.' This behaviour is standard and can be experienced in Windows Explorer and elsewhere. For instance, press 'n' followed by 'v' in quick succession while on the Desktop and notice what happens.

Impact

• This non-ideal behaviour occurs throughout the NVDA GUI. Other examples of such controls include Voice Settins>Variant combo box, Braille Settings>Output Table combo box, Braille Settings>Input Table combo box, etc.
• This bug troubles me mostly because I like to constantly switch between different ESpeak variants and I always press multiple initial alphabets consecutively as opposed to just one. I would imagine this bug to be an impediment for those looking to change the synth language, Braille table, etc. quickly as well. On the whole though, I admit that this is an issue that I might learn to live with and is not particularly high impact.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2020.2 Beta 2

Windows version:

8.1

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

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

No

If addons are disabled, is your problem still occuring?

Yes

Did you try to run the COM registry fixing tool in NVDA menu / tools?

No

[lukaszgo1]

This is not a bug technically. @bhavyashah Please note that the control used for the voice selection is a combobox whereas on the desktop we are dealing with a list view. Having said that given how many voices and Braille tables we have in NVDA settings it might be a good idea to convert these to the list views. cc @feerrenrut Could you share your thoughts from a visual perspective? Would listboxes as opposed to comboboxes be acceptable in these places?

[bhavyashah]

@lukaszgo1 I agree that this isn't technically a bug. Also, I have never understood the functional difference between a list box and a combo box. Both of them contain a number of options of which only one can be selected. Come to think of it, a web form could well use combo/list boxes in place of radio buttons and that would hardly make any difference. If there is something obvious or fundamental that I am missing here in distinguishing between these three control types, please let me know. Back to this ticket though, would it be possible to universally implement multiple initial letter navigation for combo boxes? In other words, instead of NVDA switching from combo boxes to list boxes in its GUI, how about NVDA introducing support for multiple initial letter navigation for combo boxes itself?

[josephsl]

Hi,

These three controls look differently and are intended for different purposes:

• List box: all (or part) of a list of choices will be shown on screen. As such, you can glimpse potential choices on screen and will let you scroll through list items (see add-ons list for an example).
• Combo box: a combination of an edit field and a list of choices. Only one item is shown unless the control is expanded. This is used either to save space or to let you edit items if the field supports such a state.
• Radio button: a grouping of circular buttons letting you select (check) only one item.

We have to balance between features a control offers versus screen real estate. List boxes take up most screen space, followed by radio buttons, and then combo boxes with no editing functionality unless expanded. One way to bring list boxes to life is implementing a scrollable panel which will host not only the list box, but other controls as well (for a practical example, see how Document Formatting settings panel is shown on screen).

Note: as for visual aspect of some GUI controls, you can also ask me (I used to be a low vision computer user even though I was using screen readers).

Thanks.

[Adriani90]

cc: @JulienCochuyt

[JulienCochuyt]

Actually, the current voice selection control is a drop-down list. These are often confused with combo boxes because they might look the same until focused, and also because many graphical frameworks - including wxPython - implement them as a "combo box without the edit field" while others take the approach of defining a "collapsed list box".

NVDA usually does not interfere with the standard behavior of controls, unless they have accessibility flaws. The fact that a given list control does or does not support quick selection by fast typing the first few initial letters is a characteristic that is usually not deemed an accessibility flaw. Still, I agree not implementing it is a poor choice towards ergonomics. The drop-down lists present in the GUI of NVDA are rendered using the wxPython graphical framework - which uses in that case standard Windows controls. The discrepancy between expanded list boxes and drop-down lists towards handling quick navigation by fast typing the first initial letters should thus ideally be raised at Microsoft.

Still, we probably could ease things for end users by switching from a drop-down list to an expanded yet scrollable list box. Pointing devices users would suffer a bit from the smaller real estate compared to when the drop-down list is expanded, but keyboard only users would gain better support for quick selection. I do not think we should go for a fully expanded not scrollable list box - relying on the settings panel being scrollable - because it would visually hide the rest of the voice settings options at first glance for synth, like eSpeak, that have a huge list of voices.

Regarding radio buttons, I'd say they usually take more screen estate than fully expanded list boxes depending on how you space their items, and do not come with the ability to reduce this estate by being scrollable.