nvda
nvda copied to clipboard
nvaccess
Move several settings to avoid having a combo box as the first item on a settings page
Is your feature request related to a problem? Please describe.
The most common setting I've seen people have set inadvertently is having NVDA set to laptop keyboard layout when they thought they had it set to desktop layout (usually this manifests when NVDA+down arrow only reads one line at a time).
My theory is that as the desktop / laptop setting is the first option on the keyboard page, they may be opening the page, pressing down arrow to move through options (which doesn't, it changes the value on the combo box.
Describe the solution you'd like
If that theory is correct, then my suggestion is to move a couple of settings to leave a checkbox (where the user has to explicitly press spacebar to change the value) as the first item on each settings screen.
This would affect:
- General
- Audio
- Keyboard
- Document navigation (not much to change as only one option on this screen currently)
- Windows OCR
Additional context
The only thing I thought of with this theory is that the General settings page is the first settings screen and "NVDA Language" is the first option on that and it is a combo box, so shouldn't we see more people inadvertently changing that? (we don't currently) - I don't have an answer to that, but maybe ensuring the first setting on any screen is a checkbox rather than a combo box might avoid the situation where it does occur.
The risk pointed here is to change a parameter inadvertently. If a parameter is changed but its effect is immediately noticeable, that's not a problem because the user can change the parameter back immediately without side effect.
Regarding the language change, there is less risk to change it inadvertently because:
- when you confirm the dialog, you have an explicit restart message indicating that you have changed NVDA's message
- if you change the language anyway, you can see it immediately, i.e. all the UI messages of NVDA are in another language, so you can just configure back your original language immediately and restart.
Though, I have seen recently someone having changed his/her language to a non-latin alphabet language and the TTS was not able to speak non-latin character; thus the person was just hearing nothing when navigating through NVDA menu. But that's an uncommon and exceptional case.
More generally, I think that the organization of a panel should have a logic when it is read:
- begin with more general settings and then list more specific ones
- group related settings together
Moving the controls in a panel should not go against these principles which help people to understand the options in the GUI.
For example, I think that in the OCR panel, the language is the main setting and the refresh checkbox is a more specific setting; thus, I am not convinced that switching them is a good idea.
In the specific case of keyboard layout, it's true that there are many cases of people having changed it inadvertently. Also, the new layout is not immediately noticeable, thus people get confused. In the keyboard panel, the two first controls are the most important ones and the next ones are more specific. Thus, they can be swapped if needed.
Even with these changes, I am not totally convinced that people will avoid switching keybaord layout inadvertently in the future. They still may use downArrow in a panel until they find a combo box and reproduce the same issue. By the way, I have already seen people having changed indent reporting inadvertently; I do not know if it was due to using downArrow in the doc formatting settings.
So to summarize, my opinion is that keyboard layout and NVDA key choice controls in the Keyboard settings panel may be swapped if we think that it may prevent people from switching keyboard inadvertently. Regarding the other panels, there is no need to change them, so better let them as is.
Honestly I find it hard to believe users are so careless as to navigate to the keyboard panel, and start pressing down arrow without hearing / reading on a Braille display what control they're on. If this is indeed the reason for their settings being changed inadvertently, it is unlikely any change here will improve the situation significantly - with that level of ignorance on user part there is so little we can do...
I kind of get why people would do this if they are using speech, because NVDA reads the context information before reading the control itself, so the user probably gets impatient, and starts to press down arrow, and thus only hears laptop. But since NVDA says laptop, they should know that they changed something, and not press enter afterword. Instead of changing the layout of the settings panels, I think it is better if NVDA gets the abillity to give context spesific help when the user moves the focus. e.g, press up and down arrow to move through the options in this combo box, and press tab and shift plus tab to move through the controls in this dialog, if the user is in a dialog. In this way, the user would know that they should use tab and shift plus tab to move through dialogs, instead of the arrow keys.
An alternative idea I've been wanting to suggest for a while, is to have the first focusable element in a config panel, be text-only.
We would probably have to use the read-only editable text control, which is annoying, but that aside.
When first entering a panel, one must sit through the description of the panel, before hearing the first option. Alternatively, one must tab then shift+tab, use a reading command, or such, to get the full experience of what the first control is.
Making the panel description be focusable text of some kind, would resolve the above, and the problem of this issue as well.
Or, at least, it would go as far as we could toward solving this issue, without implementing context control hints, as @Emil-18 suggested, about which I have some doubts.
The more I think to it, the more I agree with @lukaszgo1 (https://github.com/nvaccess/nvda/issues/16105#issuecomment-1914393812).
If some people can use arrows to move in a dialog and inadvertently change the value of a combo-box, changing the layout of the GUI (as suggested in the initial description or in @XLTechie's last comment) will not help so much.
If we are really concerned by the fact that people can change their keyboard layout without noticing it immediately, we may use a confirmation dialog box: "Are you sure you want to change your keyboard layout? Press Yes to confirm or No to cancel." But this seems a bit heavy to me.
If some people can use arrows to move in a dialog and inadvertently change the value of a combo-box, changing the layout of the GUI (as suggested in the initial description or in @XLTechie's last comment) will not help so much.
Here's how I think my suggestion would help in that context, @CyrilleB79.
If a user enters the settings panel, and starts hearing the description. He then presses the down arrow. But nothing happens. So he next tries tab, and hears "keyboard layout: desktop combobox collapsed".
If he then presses down arrow, and hears laptop, he will know to what it pertains, and will more likely hit up arrow to fix it.
Furthermore, by forcing him to hit tab to even reach that point, we've already trained tab as the likely forward navigation control instead of down arrow.
I know various users, especially older ones, who just try anything likely to maybe work, instead of learning proper contexts. It is hair-pullingly annoying to people trying to train them that they don't remember this stuff, but they just don't. Maybe not surprisingly, those are the same subset of users who are likely to get tired of the dialog description, press down arrow, hear "laptop", and think "oh, I better not mess with whatever that laptop option is", and next hit tab to get a better result. So making the first thing that does work, be something that doesn't run the risk of changing options, will be helpful to such people IMO.
If we are really concerned by the fact that people can change their keyboard layout without noticing it immediately, we may use a confirmation dialog box: But this seems a bit heavy to me.
Agreed, somewhat unappealing.
@Emil-18:
What are your doubts about implementing context control hints?
I would rather see this in a separate feature request, as it has far broader implications, and needs a discussion of its own. Plus, before getting into what I think may be tricky about it, I'd like a better idea of how you envision it working.
See also: the Control Usage Assistant add-on, which I believe tried this already.
@XLTechie I think it should be implemented in a similar way to how it works on VoiceOver on mac, e.g, when focus is moved, NVDA waits for a configurable amount of time, before reporting the help message for the focused control. I think that the help messages should be implemented on NVDAObjects.NVDAObject, so that custom objects can implement their own help messages. I also think that treeInterceptors also should have help messages, and that they should be reported instead of the normal help messages when NVDA is in browse mode.