Tips in system tray

[javidominguez]

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]

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]

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]

Hi, there’s another variable: is this bug present in newer Windows builds? If not, then we need to be careful about this. Thanks.

[derekriemer]

Yes, it's in win10 double reading is at least

…

On 12/21/2016 9:06 PM, Joseph Lee wrote: Hi, there’s another variable: is this bug present in newer Windows builds? If not, then we need to be careful about this. Thanks. From: James Teh ***@***.*** Sent: Wednesday, December 21, 2016 5:31 PM To: nvaccess/nvda ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [nvaccess/nvda] Tips in system tray (#6656) 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6656 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkJeUi0P_lA10wo8AdEFfqghyecK7ks5rKdK7gaJpZM4LRpkB> . — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6656 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGiveUBJqfEnGXekRMouobMU4owv_gLks5rKfc5gaJpZM4LRpkB>.

-- ------------------------------------------------------------------------ Derek Riemer * Department of computer science, third year undergraduate student. * Proud user of the NVDA screen reader. * Open source enthusiast. * Member of Bridge Cu * Avid skiier. Websites: Honors portfolio <http://derekriemer.com> Awesome little hand built weather app! <http://django.derekriemer.com/weather/> email me at derek.riemer@colorado.edu <mailto:derek.riemer@colorado.edu> Phone: (303) 906-2194

[JulienCochuyt]

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

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]

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]

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.