Move several settings to avoid having a combo box as the first item on a settings page #16105
Comments
|
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:
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:
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. |
seanbudd
added
blocked/needs-product-decision
|
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 (#16105 (comment)). 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." |
|
@XLTechie What are your doubts about implementing context control hints? |
|
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.
|
|
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. |
|
I agree with @lukaszgo1 and @CyrilleB79 here, this particular problem can also occur in other software, not only NVDA. In Ableton for example the first element in the audio settings is a combo box which lets you switch the audio driver. If you are not cautious the audio is completely lost on Ableton Window when you press down arrow in the combo box. Given the fact that the proposed solution would not fix the problem, I am closing as won't fix. |
|
This ticket has been opened by an NV Access staff member and has been labeled blocked/needs-product-decision and needs-triage by them. As per triage rules (paragraph NV Access staff-created tickets) this ticket should remain open unfortunately. Though, I agree at 200% with @Adriani90 on the fact that this ticket should be closed as "won't fix" at the end. If users use down arrow to navigate in settings, they will change a combo-box sooner or later. NVDA cannot prepare for any type of mistake and remain customizable. And it's not its philosophy at all. @Qchristensen could you please (re-)read the discussion in this ticket and close it if you agree? If you disagree, please could you provide explanations? |
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:
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 text was updated successfully, but these errors were encountered: