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

Tips in system tray #6656

Closed
javidominguez opened this issue Dec 20, 2016 · 8 comments · Fixed by #11176
Closed

Tips in system tray #6656

javidominguez opened this issue Dec 20, 2016 · 8 comments · Fixed by #11176

Comments

@javidominguez
Copy link

javidominguez commented Dec 20, 2016

In system tray with report tips checked NVDA reads twice almost all of the icons. I would not like to disable tips because in other places it can be useful but here is very uncomfortable. If tip and object name are the same text I think that NVDA should not read the tip.

@feerrenrut
Copy link
Member

feerrenrut commented Dec 21, 2016

While this is low severity, it seems like it would be fairly easy to implement, I'll set this issue to priority 2. If there proves to be edge cases I haven't considered that cause this to be harder to implement then the issue may need to be deprioritised

@jcsteh
Copy link
Contributor

jcsteh commented Dec 22, 2016

Normally, tool tips only appear when you move the mouse to an icon. The reason the tips appear in the system tray is that we have to move the mouse to the icon in order to work around a Windows focus bug.

When talking about comparing object names, the question is which objects we're comparing. Comparing the focus might make sense for the system tray case, but it doesn't necessarily make sense anywhere else. And if we compare against the mouse object, a tool tip might not get read because it has the same name, but the user really should know if the tool tip appears even if it's a duplicate. Thus, I don't agree that comparing names is a good approach here.

Instead, I think we need to special case the system tray somehow, but that is not simple to do, so I'm dropping this to a p3. I'm wondering whether this should possibly even be a p4; yes, the repetition is annoying, but you can easily ignore/silence it and it doesn't cause an efficiency problem because it is presented after other information, not before it.

@josephsl
Copy link
Collaborator

josephsl commented Dec 22, 2016

@derekriemer
Copy link
Collaborator

derekriemer commented Dec 22, 2016

@JulienCochuyt
Copy link
Collaborator

JulienCochuyt commented May 16, 2020

@jcsteh wrote:

the user really should know if the tool tip appears even if it's a duplicate.

Could you please explain what use case you have in mind? I'm not getting in which scenario a lambda end user might be misinformed by not knowing if the announce comes from a tool-tip or not. A developer is of course interested in this info, but most likely has other means to distinguish.
IMHO, duplicate announce is more annoying than not being sure of the technical underlying source of the announce - even if the user can always cut speech.

Instead, I think we need to special case the system tray somehow, but that is not simple to do

Would you by any chance have some time to share your lights on what could be the big lines of an ideal special case handling here?

@jcsteh
Copy link
Contributor

jcsteh commented May 18, 2020

the user really should know if the tool tip appears even if it's a duplicate.

Could you please explain what use case you have in mind? I'm not getting in which scenario a lambda end user might be misinformed by not knowing if the announce comes from a tool-tip or not.

In order to eliminate duplication, you have to compare against some other object. If you compare against the focus, consider the following scenario:

  1. The user focuses a button. The button is actually an icon, but it has a label for a11y.
  2. The user later decides to move the mouse around the screen to explore. (Perhaps the user has some vision.)
  3. A tooltip appears, with the same text as the a11y label for the button.
  4. NVDA compares the focus name with the tooltip name. They're duplicates, so the tooltip isn't read. The user now has no idea that a tooltip ever appeared. Note that if the user has some vision, they will see a tooltip appear, but their vision may not allow them to read its text, so they won't know what it was.

If you compare against the mouse, you'll never learn about tooltips for any object which has an a11y label matching its tooltip.

That said, I guess for most users, this probably isn't a real problem and the annoyance outweighs the slight inaccuracy.

@JulienCochuyt
Copy link
Collaborator

JulienCochuyt commented May 18, 2020

OK, thanks, I guess we're on the same track here.
The relevant info is not that the announce comes from the focus or from the mouse.
The important point is that an announce is made,
With NVDA becoming lastly more and more friendly towards low-vision users, the user base has grown significantly. As long as the annoyance of the duplication can be removed for our primordial target audience, that is users with no vision at all, I think we can make the effort to maintain a reliable mouse hovering behavior.
Thus, I guess this special case is likely to be handled at appModules.explorer.NotificationArea class level. Oddly, I can't find there NVDA moving the mouse on the icons as mentioned in #6656 (comment) but only the mouse being moved away... I'll have a deeper look.

@JulienCochuyt
Copy link
Collaborator

JulienCochuyt commented May 18, 2020

Further testing, I can confirm that, at least on Windows 10, the tool-tip appears not because of NVDA moving the mouse, but because of the icon being focused.
With NVDA being shutdown, hitting windows+b to focus the systray then focusing individual icons with left and right arrows, the tool-tip does appear, despite the mouse not apparently moving.
Indeed, NVDA moves the mouse away to avoid focus bouncing in case the mouse was on the systray.
By the way, this behavior could be refined to avoid moving the mouse if it wasn't there in the first place. Also, at least on Windows 10, this behavior is only effective after a first failure.

JulienCochuyt added a commit to accessolutions/nvda that referenced this issue May 18, 2020
feerrenrut pushed a commit that referenced this issue Jun 9, 2020
…stray icon name (PR #11176)

Fixes #6656

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

Additionally, to avoid focus jumps, NVDA was moving the mouse cursor to the top left corner of the screen as soon as a systray control gained focus via keyboard navigation.

In appModules.explorer:
Now 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, now 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.
@nvaccessAuto nvaccessAuto modified the milestone: 2020.2 Jun 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants