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

Status: NEW

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

Description

[Jeremy M. Dolan]

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.

Comment 1

[sairuh (rarely reading bugmail)]

is there an existing bug for this already...?

Comment 2

[Aaron Leventhal]

-> mpt, for UI feedback

Comment 3

[Aaron Leventhal]

I'll take this one.

Comment 4

[Matthew T (active 1999-2002)]

Yes, but the tooltip should only appear after the same delay as applies to the 
mouse when hovering over the item.

Comment 5

[Kyle Yuan]

*** Bug 145743 has been marked as a duplicate of this bug. ***

Comment 6

[Aaron Leventhal]

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.

Comment 7

[Gilles Durys]

*** Bug 202766 has been marked as a duplicate of this bug. ***

Comment 8

[jonathan chetwynd]

onfocus

Comment 9

[jonathan chetwynd]

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.

Comment 10

[Aaron Leventhal]

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).

Comment 11

[jonathan chetwynd]

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.

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

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

Comment 13

[Henri Sivonen (:hsivonen)]

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?

Comment 14

[Patrick H. Lauke]

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)

Comment 15

[sailesh.panchang]

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

Comment 16

[Asa Dotzler [:asa]]

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

Comment 17

[sailesh.panchang]

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

Comment 18

[robert.vuj.linder]

(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

Comment 20

[:Gijs (he/him)]

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

Comment 21

[:Gijs (he/him)]

(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?

Comment 22

[Patrick H. Lauke]

"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.

Comment 23

[:Gijs (he/him)]

(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.

Comment 24

[Patrick H. Lauke]

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

Comment 25

[robert.vuj.linder]

(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>).

Comment 26

[Chris Peterson [:cpeterson]]

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

Comment 27

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 28

[Olli Pettay [:smaug][[e-mail]]]

We'd probably want to bind this to tabbing and less to the code in
https://searchfox.org/mozilla-central/rev/21a9b72545da06681db97c4b3a2a6be761f4aae5/docshell/base/nsDocShellTreeOwner.cpp#1057

Comment 29

[James Teh [:Jamie]]

(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.

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Comment 31

[robert.vuj.linder]

This issue was brought up in CSSWG issue #8930 discussing standardizing native tooltips for styling.

Comment 32

[Anna Yeddi [:ayeddi]]

Did a quick check of the current status, since the issue is still present in Firefox and we could do better.

Checking browsers showing the HTML title tooltip on web content and tooltips that visually appears as HTML title tooltips on the chrome controls, when the control with a tooltip is focused with keyboard:

1. Firefox 149 WinOS and MacOS is not showing it on either web content or chrome elements ❌ ❌.
2. Safari 26.2 MacOS is not showing it on either web content or chrome elements ❌ ❌.
3. Chrome:
   1. WinOS 144 is showing the tooltip on chrome items ✅, but not on the web content ❌. Example of chrome item: "Bookmark this tab" and other toolbar buttons.
      1. Delay is probably over 1 sec, similar to hover delay (personally, I found it lagging)
   2. MacOS 144 is not showing the tooltip on either web content or chrome elements ❌.
4. Edge 144 is showing the tooltip on both chrome items and web content ✅ ✅. Example of chrome item: "Add this page to favorites (Ctrl + D)" and other toolbar buttons.
   1. Delay is probably within 1 sec, similar to hover delay (personally, I found it fast enough)

• Test case for web content: data:text/html,<button title="Can you see me?"/>Focus%20me, but would work for the browser's Settings controls (i.e. ? "Learn more" button on edge://settings/help)

Comment 33

[James Teh [:Jamie]]

Elevating this to access s2 because without this, a keyboard only user who does not use a screen reader is completely unable to access these tooltips.