Open Bug 97223 Opened 23 years ago Updated 1 year ago

tabbing to element (focusing it by keyboard) should bring tooltip (contents of title attribute) up

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
enhancement

Tracking

()

Project Flags:
Accessibility Severity s3

People

(Reporter: jmd, Unassigned, NeedInfo)

References

Details

(Keywords: access, helpwanted, parity-chrome) 

Tabing to a link with a title, for example, doesn't popup the title as a
tooltip. This is a severe usability problem on certain sites for users that have
difficulty using a mouse.
is there an existing bug for this already...?
Summary: tabing to element should be same as moving mouse to → tabbing to element should be same as moving mouse to
Whiteboard: DUPEME?
-> mpt, for UI feedback
Assignee: aaronl → mpt
Summary: tabbing to element should be same as moving mouse to → tabbing to element should bring tooltip up
I'll take this one.
Assignee: mpt → aaronl
Yes, but the tooltip should only appear after the same delay as applies to the 
mouse when hovering over the item.
OS: Linux → All
Hardware: PC → All
*** Bug 145743 has been marked as a duplicate of this bug. ***
Summary: tabbing to element should bring tooltip up → tabbing to element (focusing it by keyboard) should bring tooltip (contents of title attribute) up
Whiteboard: DUPEME?
Keywords: access
This will be useful for type ahead find, so that we can search in the tooltips
of links as well. We would show as selected the found part of the tooltip.
Blocks: atfmeta
Keywords: helpwanted
*** Bug 202766 has been marked as a duplicate of this bug. ***
onfocus
What is the delay on this bug?

20 months seems like a long time for what seems a fairly trivial problem with
great benefits for a significant number of users.
I'm waiting for the W3C Web API group to say that onfocus should hover, (also that an Enter keypress should fire an onclick, but that's anoither matter).
Assignee: aaronleventhal → nobody
Blocks: keya11y
Aaron,

Do we have a due time?

what can the downside to implementation be?

This bug was raised nearly five years ago!

It's true that W3C/WAI isn't that well integrated into the other standards. 
Meanwhile, everyone learns to use something more difficult than it needs to be.
OR doesn't.
Severity: normal → enhancement
Blocks: fox3key
No longer blocks: keya11y
No longer blocks: fox3key
QA Contact: bugzilla → keyboard.navigation
I think we should do this with the delay suggested in comment 4.

Note there are related guides on this topic:
http://www.w3.org/TR/wai-aria-practices/#AuthDefKeys
http://dev.aol.com/dhtml_style_guide#tooltip
When the focus is on an element, is there a way to explicitly ask for the tooltip to be rendered by pressing a magic key combo?
possibly of interest: IE11/Win8 does this by default now (tab to, say, a link with a title attribute and - after the same delay as mouse-based tooltip - the tooltip appears)
It is especially useful  for image icons  used in controls whose meaning is not clear to all users in different contexts in which the same icon is used.
A button or link with no text content  that contains the image can be assigned  an aria-label and role=button (or link) and be made screen reader accessible but it will not help some sighted keyboard users.
If the title text is displayed as a caption for the element (when one swipes to it  on Mobile-Firefox or when one tabs to the element on a laptop) , then it will help all.
It will also work as an accessible name  assigned by a native HTML attribute and will not require aria-label...  which is not visible even with mouseover unlike the title.  
There are lots of other uses of the title where it serves as an accessible description and is available on mouseover but is not generally available to keyboard users. This should be fixed.
As Firefox is a widely used browser and at the forefront of  implementing browser UI features, I request you  like others before me on this thread to  consider this suggestion for implementation at the soonest.
IE 11 and Microsoft Edge support the title attribute vvia the keyboard.
The 'title' attribute  has been around in HTML for a very long time but it is disheartening that keyboard support has not existed for it.

I am not in support of  a user querying  an element to check if it has a title ... like users of VO on a Mac do for aria-describedby or Win-Eyes do for the title.
Thanks and regards,
Sailesh Panchang

In my testing, Edge does show the tooltip with a short delay. Chrome does not show the tooltip.

That is already noted. See the previous comment #15 of 2 years ago.

Component: Keyboard: Navigation → User events and focus handling

(In reply to Asa Dotzler [:asa] from comment #16)

Chrome does not show the tooltip.

This is now being implemented in chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=829352

The tooltip implementation that listens for events and calls frontend code to show/hide stuff lives in docshell, so moving this bug.

Component: DOM: UI Events & Focus Handling → DOM: Navigation

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from bug 1743508 comment #9)

Thank you Gijs. I just wanted to redirect handling this bug to somebody who is familiar with here. Perhaps, this bug is not urgent one so that we should put this to the backlog of the DOM team.

I think if all the other browsers are implementing this, it'd be unfortunate if we were left as the less accessible browser. As I noted in bug 1743508 comment 8, to fix this in theory all we need is the right event listeners in the docshell code that currently uses mouse tracking only for deciding to show/hide tooltips. Asa, can you help with the priority / who could work on this?

Severity: normal → --
Flags: needinfo?(asa)

"if all the other browsers are implementing this"

As the only browsers that implemented this behaviour were IE11 and the original Edge, and that IE is now EOL and Edge has dropped this when they moved to using Blink, I'd say that the momentum here is now definitely gone. if this bug had been looked at, say, 10 years ago or so, it might have stood a chance to push other browsers to follow suit as well, but at this point in time, Firefox would be an outlier in doing it.

(In reply to Patrick H. Lauke from comment #22)

"if all the other browsers are implementing this"

As the only browsers that implemented this behaviour were IE11 and the original Edge, and that IE is now EOL and Edge has dropped this when they moved to using Blink, I'd say that the momentum here is now definitely gone. if this bug had been looked at, say, 10 years ago or so, it might have stood a chance to push other browsers to follow suit as well, but at this point in time, Firefox would be an outlier in doing it.

My understanding from other comments and the chromium ticket is that Blink is implementing.

See Also: → https://bugs.chromium.org/p/chromium/issues/detail?id=829352

ah, my apologies, missed the chromium link there...

(In reply to Patrick H. Lauke from comment #22)

"if all the other browsers are implementing this"

Edge has dropped this when they moved to using Blink

In Edge v96.0.1054.43 tooltips are displayed on focus (from the title attribute, though seemingly not from SVG <title>).

We need to investigate Chrome's behavior.

DocShell needs to tell frontend to show the tooltip. Nika says this bug would be fixed in ChromeTooltipListener:

https://searchfox.org/mozilla-central/rev/21a9b72545da06681db97c4b3a2a6be761f4aae5/docshell/base/c#946

WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=61732

Severity: -- → N/A
Component: DOM: Navigation → DOM: UI Events & Focus Handling
Keywords: parity-chrome
See Also: → https://bugs.webkit.org/show_bug.cgi?id=61732

FYI to Jamie; the chrome bug is an accessibility bug per comments and classification there

Flags: needinfo?(jteh)

(In reply to Olli Pettay [:smaug] from comment #28)

We'd probably want to bind this to tabbing

I assume you mean this would only work for tabbing and not other methods of taking focus?

Does anyone know if Chromium displays tooltips for other methods of taking focus? (I can't check this myself since I'm blind and can't see the tooltips.)

The reason this might be relevant is alternative input methods such as assistive switch devices or eye trackers, used by people with limited mobility. Switch control isn't standardised on Windows, making it difficult to know how to best serve these users. I believe some switches simulate the tab key, but others may not. Microsoft is trying to standardise eye tracking with Windows Eye Control, though I don't know if all eye trackers are supported yet and what proportion of users have switched over to it.

Flags: needinfo?(jteh)
Whiteboard: [access-s3]
Whiteboard: [access-s3]
Accessibility Severity: --- → s3
You need to log in before you can comment on or make changes to this bug.