Skip to content

Avoid reporting systray tool-tips if their text equals the focused systray icon name (#6656)#11176

Merged
feerrenrut merged 3 commits into
nvaccess:masterfrom
accessolutions:i6656-systray
Jun 9, 2020
Merged

Avoid reporting systray tool-tips if their text equals the focused systray icon name (#6656)#11176
feerrenrut merged 3 commits into
nvaccess:masterfrom
accessolutions:i6656-systray

Conversation

@JulienCochuyt

Copy link
Copy Markdown
Contributor

Link to issue number:

Fixes #6656

Summary of the issue:

When navigating the systray using the keyboard and tool-tips reporting is enabled, most systray icon names are double announced as their name is usually equal to the tool-tip text.

Additionally, to avoid focus jumps, NVDA moves the mouse cursor at the top left corner of the screen as soon as a systray control is gains focused as of keyboard navigation.

Description of how this pull request fixes the issue:

In appModules.explorer:
Do not report if:

  • the focus is in the systray
  • and the mouse has not indeed recently been moved
  • and the mouse is located in the systray
  • and the name of the focused systray icon equals the tool-tip text.
    Report as usual in any other case.

Additionally, do to reset the mouse cursor position to the top left screen corner upon navigating with the keyboard to the systray if the mouse wasn't their in the first place.

Testing performed:

Ensured systray icons tool-tips are still always reported when actually hovered with the mouse.
Ensured other Explorer tool-tips are still reported, whether they appear due to mouse hovering or keyboard navigation.
Ensured the mouse cursor position is not reset upon systray keyboard navigation if the mouse is not over the systray.
Ensured the mouse cursor position is reset upon systray keyboard navigation if the mouse is over the systray and has not voluntarily been moved there.

Known issues with pull request:

Change log entry:

Section: Bug fixes
The tool-tips of the icons in the system tray are no longer reported upon keyboard navigation if their text is equal to the name of the icons, to avoid a double announce.

@lukaszgo1 lukaszgo1 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be great to generalize this to other buttons in Windows Explorer exhibiting this behavior i.e. names of apps pinned to Taskbar or buttons used to open task view / people on Windows 10. It should be sufficient to check if the object with focus has a role of button and if its text equals this of the tool tip.

Comment thread source/appModules/explorer.py Outdated
Comment thread source/appModules/explorer.py Outdated
@JulienCochuyt

Copy link
Copy Markdown
Contributor Author

@lukaszgo1 wrote:

I'd be great to generalize this to other buttons in Windows Explorer exhibiting this behavior i.e. names of apps pinned to Taskbar or buttons used to open task view / people on Windows 10.

I agree.

It should be sufficient to check if the object with focus has a role of button and if its text equals this of the tool tip.

I also took care here to maintain the current announcement on mouse hovering.
Question is, which is more painful for low-vision users: double announce or badly seeing something appearing and not being informed/reassured that it was a tool-tip? That is, should we also suppress the double announce on mouse hovering or merge as-is?

cc @javidominguez, @jcsteh, @feerrenrut, @josephsl (participants to #6656)

@Adriani90

Copy link
Copy Markdown
Collaborator

I guess a low vision person would move the mouse back and forth to hear the object and would not wait for double announcement. So imo double announcement should be suppressed as well.

@lukaszgo1

Copy link
Copy Markdown
Contributor

@JulienCochuyt wrote:

@lukaszgo1 wrote:

I'd be great to generalize this to other buttons in Windows Explorer exhibiting this behavior i.e. names of apps pinned to Taskbar or buttons used to open task view / people on Windows 10.

I agree.

It should be sufficient to check if the object with focus has a role of button and if its text equals this of the tool tip.

I also took care here to maintain the current announcement on mouse hovering.
Question is, which is more painful for low-vision users: double announce or badly seeing something appearing and not being informed/reassured that it was a tool-tip? That is, should we also suppress the double announce on mouse hovering or merge as-is?

IMO we should not. Moving mouse to the given control is a explicit action and for a low vision user mouse is a primary input device so he either moves it fast enough not to be concerned with these duplicate announcements, or he is interested in the fact that tool tip appeared. The latter case might also be useful for developers in some cases as a quick way to check if tool tip exists but is not announced by the screen reader as it is a duplicate or not.

@feerrenrut feerrenrut merged commit 557583b into nvaccess:master Jun 9, 2020
@nvaccessAuto nvaccessAuto added this to the 2020.2 milestone Jun 9, 2020
feerrenrut added a commit that referenced this pull request Jun 9, 2020
@JulienCochuyt JulienCochuyt deleted the i6656-systray branch June 9, 2020 13:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tips in system tray

5 participants