Open Bug 1468007 Opened 8 years ago Updated 8 months ago

abbr title isn't visible to keyboard only & mobile users

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P5)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
60 Branch
Type:
defect

Tracking

()

People

(Reporter: mike, Unassigned)

References

(
URL
)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180605171542 Steps to reproduce: Try to display the title of an abbreviation like <abbr title="World Health Organization">WHO</abbr> without a mouse or screen reader. Keyboard only users can't focus on it. Not sure that mobile users can either Actual results: You can't display it without hover. Expected results: I'd be able to see a World Health Organization tool-tip like you do on hover.
Reproducible on desktop side on latest 60 Release and 62 Nightly, but I'm not particularly sure if this is something that should be fixed browser side, therefore I will initially triage this in the keyboard navigation to get additional opinions.
Status: UNCONFIRMED → NEW
Component: Untriaged → Keyboard: Navigation
Ever confirmed: true
Product: Firefox → Core
Sorry, but where else would this issue be fixed? There is no AT involved. With mobile users it's the same thing, other than it isn't available to anyone.
(In reply to Mike Gifford from comment #3) > Sorry, but where else would this issue be fixed? There is no AT involved. > With mobile users it's the same thing, other than it isn't available to > anyone. IMO, it kinda'of makes sense to me not to be able to focus it with keyboard, since abbr is in essence a tool tip, so my expectations for it are to work on hover. Also, nowadays most of the existing mobile devices have touch screens, so I'm at a loss why this could be a problem for mobile. Just to clarify, my opinion is a bit trivial, so in comment 2, I just triaged this bug and set an initial component in order for this bug to be discussed in a better suited section of Bugzilla. Apologies if that was confusing.
URL: https://developer.mozilla.org/en-US/d...
The same problems apply to tool tips in general. It's a flawed pattern for many with disabilities. I don't know if I can use HTML here but <abbr title="Web Content Accessibility Guidelines">WCAG</abbr> guidelines don't give exceptions for tool tips. How do you hover on a tooltip with a smart phone? It's click or nothing last I checked.
https://developer.paciellogroup.com/blog/2013/01/using-the-html-title-attribute-updated/ seems to indicate comment 0's example is "NOT USEFUL or are of LIMITED USE" (caps in the article). Am I reading that correctly?
Flags: needinfo?(mike)
the limitation to it's usefulness is because of browser implementation: "The title on the abbr element is well supported by screen reader software, but its use is still problematic, as other user groups cannot access the expansion. It is recommended that the expanded form of an abbreviation is provided in plain text when it is first used in a document, and/or a glossary of terms that provides the expanded form is provided. This is not to suggest that that the expansion should not be provided using the title attribute, only that due to its limitations, an expansion in plain text should also be provided." So because browsers don't make good use of this, relying on the title attribution is problematic. This is a good place to change that so that keyboard only users and other assistive technology users can benefit from the description of the abbreviation.
Flags: needinfo?(mike)
OK, let's get Alex into the conversation as he's the accessibility module owner.
Flags: needinfo?(surkov.alexander)
@title and abbr is indeed a problem when there's no mouse, but this is rather UX thing than accessibility one. However how about adding a small reference on the top corner of an element, maybe a question mark link, and when you click it, a popup appears? It would solve the problem, but might be felt heavy for the user interface.
Flags: needinfo?(surkov.alexander)
This is bug 97223 or bug 273704, right?
(In reply to Anne (:annevk) from comment #10) > This is bug 97223 or bug 273704, right? I like the idea, however it seems doens't solve the problem for not focusable or not tabable elements.
This is a long-standing cross-browser problem. I don't expect us to prioritize resourcing to pursue this actively, but I'm leaving this open instead of outright WONTFIXing in case someone comes up with a solution that's acceptable both to users and to Web authors and is willing to implement the solution, too.
Priority: -- → P5
Component: Keyboard: Navigation → User events and focus handling

Hello there.
I'm glad to see that other people have also reported this UI/UX issue with Firefox mobile.

THE PROBLEM IN SHORT:

<abbr> and <acronym> HTML tags are not shown in mobile Firefox for Android

THE PROBLEM IN DEPTH:

There is no visual indication of the HTML <abbr> and <acronym> tags in Mozilla Firefox for mobile devices (e.g. Firefox for Android) OR there is a visual indication of these HTML tags (tested under Mozilla Firefox v66.0.2 for Google Android v8) and it is a dotted underline BUT the 'title=' text isn't displayed in any way...

SUGGESTED SOLUTION:

Make changes to show a dotted underline for <abbr> and <acronym> tags (DONE as of Firefox v66.0.2 for Android!!!)
and then show a word-wrapped (for UI/UX purposes - so it doesn't get shown off-screen) semi-transparent (translucent, e.g. semi-transparent yellowish with the text being in black #000000 with white-shadow) pop-up with the 'title=' text contents when the user taps/clicks on the underlined text.

For optimal results, the pop-up should stay visible after being triggered to shown UNTIL the user taps/clicks elsewhere OR until the user clicks on the pop-up again OR until the user clicks on the [X] mini-icon of the pop-up.
This is to ensure that the 'title=' text is both selectable and copyable, AND is read/detected by text-to-speech screen-readers!

Some useful related code with ideas about how to implement this ToolTip pop-up for <abbr> and <acronym> tags:

EXPECTED RESULT:

  1. As of Firefox v66.0.2. for Google Android, the <abbr> and <acronym> tags are indicated as with the desktop Firefox - via a dotted underline BUT the tooltip text is still not shown in any way.
  2. After implementing the solution described above, when a user sees such a dotted underlined text, the user can tap/click on it, and a semi-transparent (so as not to cause UX problems by hiding what's behind it too much!) pop-up (done with CSS and/or JavaScript, NOT a browser pop-up!) like that of qTip2 will show the 'title=' text and that text is both selectable and copyable (for UX purposes!). The tooltip pop-up and its shown text SHOULD be word-wrapped and shouldn't exceed the mobile-browser's view-port dimensions, i.e. should flow downwards while still having some space around them for mobile-navigation.
  3. To close that pop-up, the user just taps/clicks elsewhere around the dotted underlined text OR taps on the pop-up once to close it OR just taps on the [X] mini-icon of the pop-up to close it (see: qTip2).

Test pages (yeah, I know that w3schools isn't as up-to-date as the WHATWG.org's HTML5 spec or Mozilla's MDN docs but bear with me!):

TO DO: Actually implement it via CSS and/or JavaScript (see 'related code with ideas' above for starting points).

P.S. Thanks to all the nice people who contributed to this bug-report!

Any progress/ETA on a browser-wide solution? There have been good solutions suggested already, that would at least partially solve the issue, which would already be much better than what we have now.

I was just on Wikipedia and someone took the time to use the right tag to display an abbreviation's meaning, and to my surprise, I had no way of reading said meaning on my phone. As someone who primarily uses my phone to browse the Internet, that (as well as how badly mobile optimized Bugzilla is!) felt really anachronistic.

I currently feel like I've been thrust back in 2012, back when mobile websites were a cool, newfangled thing, not the dang minimum it is today.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.