Repository: nvaccess/nvda

Issue:
Alt+a focuses but does not select "annotations" in NVDA Elements list dialog in Word
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.



Discussion:
@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?
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.
In the French locale, we also have a collision with the access key "C" between Form fields ("**C**hamps de formulaire") and Activate ("A**c**tiver").
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 "**M**ove 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.

Resolving patch:
diff --git a/source/browseMode.py b/source/browseMode.py
--- a/source/browseMode.py
+++ b/source/browseMode.py
@@ -972,9 +972,10 @@ def __init__(self, document):
 		contentsSizer.AddSpacer(gui.guiHelper.SPACE_BETWEEN_VERTICAL_DIALOG_ITEMS)
 
 		bHelper = gui.guiHelper.ButtonHelper(wx.HORIZONTAL)
-		# Translators: The label of a button to activate an element
-		# in the browse mode Elements List dialog.
-		self.activateButton = bHelper.addButton(self, label=_("&Activate"))
+		# Translators: The label of a button to activate an element in the browse mode Elements List dialog.
+		# Beware not to set an accelerator that would collide with other controls in this dialog, such as an
+		# element type radio label.
+		self.activateButton = bHelper.addButton(self, label=_("Activate"))
 		self.activateButton.Bind(wx.EVT_BUTTON, lambda evt: self.onAction(True))
 		
 		# Translators: The label of a button to move to an element


Test patch: