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

[Qchristensen]

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.

[bhavyashah]

@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]

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]

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]

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…

[CyrilleB79]

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]

@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]

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]

@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"?