Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alt+a focuses but does not select "annotations" in NVDA Elements list dialog in Word #6167

Closed
Qchristensen opened this issue Jul 11, 2016 · 8 comments · Fixed by #12369
Closed
Labels
p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Milestone

Comments

@Qchristensen
Copy link
Member

In Browse mode, in Word, pressing NVDA+F7 brings up the elements list dialog. The K in Links, H in Headings and A in Annotations are all underlined visually. Pressing alt+k focuses AND selects Links (so you can then press TAB to go to the list of links. Pressing alt+h for headings works the same way. Pressing alt+a works differently: It moves the focus to the annotation radio button but does not activate it as the "Activate" button (for launching links) also uses the alt+a shortcut (even if there aren't any links and the "activate" button is disabled). If the focus is currently on links (the default) and there is at least one link, pressing alt+a activates the currently selected (or fist) link.

My initial feeling is to question whether the "activate" button needs an "alt+letter" shortcut, given that when it is available it becomes the active button so the easiest way to launch a link is to location it in the elements list and press ENTER rather than ALT+A.

@michaelDCurran michaelDCurran added the p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Jul 11, 2016
@bhavyashah
Copy link

@Qchristensen To be clear, the expectation is that Alt+A as the shortcut for the Activate button should be removed not just for Elements list in Word browse mode, but Elements list across the board (web, HTML documents, etc.), right?

@Qchristensen
Copy link
Member Author

Is there a use case for having alt+a assigned to activate? EG, I can't think of a workflow other than locate a link in the list, then (press command) to activate it. At that point, you can press ENTER. Would anyone ever locate a link in the elements list, navigate away from the link (eg tab to the cancel button and THEN press alt+a)?

Removing alt+a from the activate button (but leaving that button as the default button while a link is selected) shouldn't change the workflow for anyone wanting to activate links, but would make it easier to get to "annotations" as well as consistent with navigating to the other element types.

@JulienCochuyt
Copy link
Collaborator

In the French locale, we also have a collision with the access key "C" between Form fields ("Champs de formulaire") and Activate ("Activer").
While this is obviously not a bug, this is not as ergonomic as can be especially for less advanced users.

Beware though not to remove the "Move to" letter "M" access key, as it is useful to trigger the secondary action when both are available.

Also note that the "Activate" button being the default action is not denoted as should be by the corresponding standard visual cue - neither is "Move to" when "Activate" is unavailable.

JulienCochuyt added a commit to accessolutions/nvda that referenced this issue May 5, 2021
…tton (nvaccess#6167)

Note to translators: Beware not to set an accelerator that would collide with other controls
in this dialog, such as an element type radio label.
@JulienCochuyt
Copy link
Collaborator

Also note that the "Activate" button being the default action is not denoted as should be by the corresponding standard visual cue - neither is "Move to" when "Activate" is unavailable.

Well, I've played with this and I can't seem to be able to set the visual cue only when the focus is in the tree.
It does get removed upon leaving the tree, but is visually refreshed only when alt-tabbing back to the dialog…

michaelDCurran pushed a commit that referenced this issue May 9, 2021
…tton (#6167) (#12369)

Fixes #6167

Summary of the issue:
In the English locale, there is an accelerator key collision between the "Annotation" element type and the "Activate" button, both set to the letter "A".
In the French locale, there is collision between the element type "Form field" ("Champs de formulaire") and the same button ("Activer"), both set to the letter "C".
This changes the behavior of the accelerator key that focuses the radio button but does not activate it.
This is not a bug at all, but is not ergonomically optimum, especially for less advanced users.

Description of how this pull request fixes the issue:
As suggested by @Qchristensen, remove the accelerator key setting from the "Activate" button as it is, when available, the default action of the dialog upon pressing the enter key.
In most locale, this change should not raise the need for a new translation, as the "Activate" label already exists without an accelerator marker as "a message reported when the action at the position of the review cursor or navigator object is performed.".
Just to be sure, I also added a warning in the translators comment for the button label to ask them to beware of the risk of collision.
@nvaccessAuto nvaccessAuto added this to the 2021.1 milestone May 9, 2021
@CyrilleB79
Copy link
Collaborator

I just discover (a bit lately) this issue and the recently merged associated PR. Please let me add comments on it. Some points are not very clear to me.

@JulienCochuyt you write:

In the French locale, we also have a collision with the access key "C" between Form fields ("Champs de formulaire") and Activate ("Activer").
While this is obviously not a bug, this is not as ergonomic as can be especially for less advanced users.

Such collisions are not intended and, in French translation team, we try to avoid or resolve them. If you notice other collision in translation, feel free to report it directly to us or on the nvda-fr mailing list.

@Qchristensen you write:

Is there a use case for having alt+a assigned to activate? EG, I can't think of a workflow other than locate a link in the list, then (press command) to activate it. At that point, you can press ENTER.

Maybe I missed something obvious, but:
As a user, how do I know that the "Activate" button is the default action, i.e. that it will be triggered by pressing Enter on a link? For me, it is all but obvious.
Also the default button is "Go to" for form fields, headings and landmarks, but "Activate" for links and buttons. IMO this make things more confusing.

Note: By this comment, I just wanted to inform of what seemed quite strange to me. However this comment is not triggered by a real-life experience since I am not a frequent user of the element list.

@JulienCochuyt
Copy link
Collaborator

@CyrilleB79 wrote:

If you notice other collision in translation, feel free to report it directly to us or on the nvda-fr mailing list.

I didn't notice this collision until I found this ticket. I actually entered the French translation team myself (though I'm not very active there) to fix another collision a while ago.

As a user, how do I know that the "Activate" button is the default action, i.e. that it will be triggered by pressing Enter on a link? For me, it is all but obvious.

I agree with you here. I've tried with no great success to enforce standard visual cue on that matter, but even that wouldn't solve at all the needs of most new NVDA users. Maybe some kind of tutor message announced after the selected element in the tree might help.

Also the default button is "Go to" for form fields, headings and landmarks, but "Activate" for links and buttons. IMO this make things more confusing.

I disagree here. "Activate" is the default and "Go to" the secondary action, unless the type of element you choose in the first place cannot be activated (eg. headers) in which case the sole available "Go to" is the default. This makes for a pretty straightforward workflow once you've been introduced to it. You're of course fully legitimate to criticize it and try to improve it, but I never received any complaint about it earlier and I've met quite a lot of users of this feature.

Btw., the performance aspect of the Elements List - especially on large documents - is IMHO a much bigger issue.
See issue #7197 / PR #10308. I'll try to come back on this one some day.

@CyrilleB79
Copy link
Collaborator

Also the default button is "Go to" for form fields, headings and landmarks, but "Activate" for links and buttons. IMO this make things more confusing.

I disagree here. "Activate" is the default and "Go to" the secondary action, unless the type of element you choose in the first place cannot be activated (eg. headers) in which case the sole available "Go to" is the default. This makes for a pretty straightforward workflow once you've been introduced to it. You're of course fully legitimate to criticize it and try to improve it, but I never received any complaint about it earlier and I've met quite a lot of users of this feature.

Sorry, I guess I did not make myself well understood.
I do not advocate to make "Go to" button the default one for all type of elements. I agree that "Activate" is relevant for being the default action when the element supports it and that "Go to" is relevant for elements that do not support activation. <Users seem to be happy with it and this should remain as is because it is the most efficient.
I was just pointing that it is hard for a new user to know what is the default action without experimenting. And that having the default action changing according to the selected element type does not help.
If possible, a tutor message seems to be a good solution.

Btw., the performance aspect of the Elements List - especially on large documents - is IMHO a much bigger issue.
See issue #7197 / PR #10308. I'll try to come back on this one some day.

Fully agree here.

@JulienCochuyt
Copy link
Collaborator

@Qchristensen,
May we have your experienced thoughts on this topic?
What would you think of the addition of a tutor message to inform the user of the default action?
Eg. when moving selection in the tree list, something like "Some fancy header, level 1, press enter to move there" / "Some fancy link, press enter to activate"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Projects
None yet
6 participants