content: Tool-tip post has problematic accessibility info

[aardrian]

What page(s) need to be updated?

https://web.dev/building-a-tooltip-component/

Why is this update needed?

2 significant changes needed, 3 changes warranted, 2 bits of feedback:

1. The demo is 404

I realized I could file a PR to fix that, so I did: #8958

2. WCAG violations

The tool-tip demo as written creates a WCAG Success Criterion 1.4.13: Content on Hover or Focus failure:

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

• Dismissible
  A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
• Hoverable
  If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
• Persistent
  The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

The specific WCAG violations:

• When I hover or use the keyboard to put focus on the trigger, I cannot dismiss the tool-tip without moving away from the trigger. This violates the Dismissible clause.
• When I move my pointer to the tool-tip to try to copy the content, the tool-tip disappears. This violates the Hoverable clause.

3. Inaccurate description of screen reader

From the article:

Now, to screen readers, it's recognized as a tooltip. See in the following example how the first link element has a recognized tooltip element in its tree and the second does not? The second one doesn't have the role. In the styles section we'll improve upon this tree view.

That screen shot is from the Chrome developer tools. That represents what Chrome sends, not necessarily how something is exposed, recognized, nor announced. While the distinction may seem small, it feeds into the ongoing misunderstanding of where browsers stop and screen readers start, resulting in blame landing on the wrong tools when things don't work as developers expect.

4. Advice makes tooltip part of accName / content

From the article:

Finally, place elements inside of the element you wish to provide a tooltip for. Here I share the alt text with sighted users by placing an image and a inside of a element:

The code presented makes the tooltip part of the content itself, meaning a screen reader use in particular is required to hear it. The ARIA spec on the tooltip role is clear that it should be part of the accDescription, not the accName:

Authors SHOULD ensure that elements with the role tooltip are referenced through the use of aria-describedby before or at the time the tooltip is displayed.

If you want to dive more into the tooltip role, I encourage you to read this ARIA discussion: #979 Clarify the use of role=tooltip

5. Localization concern

From the article:

Add a screen reader only pseudo-element to the and we can add our own prompt text for non-sighted users.

1. Not all screen reader users are blind.
2. CSS generated content will not translate via automated tools.
3. It is verbose.

6. Probably do not use Designcember as an example

The Designcember site has problematic disclosures / tool-tips. I raised this issue last year. The author acknowledged it. Even now it is problematic (although I am pleased to see the modals dismiss on Esc). I encourage you not to use it as an example.

7. Abbreviation freebie

I know the <abbr> is used only as an example, but a best practice is to not use it (since it is not accessibility supported) and expand the text as you would the printed page. Eg: HyperText Markup Language (HTML).

8. Remove autoplay

While I am here, can you please remove the autoplay on the Designcember example and allow the controls to display? Doing so will get around the current SC 2.2.2: Pause, Stop, Hide issue.

What's the deadline?

Ideally before anyone copies this code into their projects, given using it will create a WCAG conformance error and potentially expose them to legal risk (low risk, but still).

[patrickhlauke]

just here to +1 this. it's...embarassing that this sort of content gets pushed out without being fully vetted/reviewed. it'll just end up being cargo-culted by developers mistakenly thinking that it's production-ready and road-tested.

[smhigley]

A +1 to this issue from me, and a few additions:

inert

The article's entire accessibility approach relies on an inert child being part of its parent's accessible name. While that currently happens in Chromium, I don't believe that is a safe assumption going forward. While it isn't in HTML AAM yet, my assumption is that inert should map to aria-hidden=true (which is what the polyfills do), and a node with aria-hidden=true will not be included in the parent's accessible name.

This means that the text of all the tooltips in the article would not be exposed to screen reader users at all. This is a major accessibility issue, and should be corrected ASAP, in my opinion.

---

name vs. description

I also want to just emphasize how big a problem this recommendation is:

&::before {
  content: "; Has tooltip: ";
  ...
}

In addition to asking for screen-reader-only localization problems, the fact that this text is added is a clear signal that the tooltip should be a description, not part of the name (as Adrian mentioned).

I'm actually not strongly opposed to the idea of broadening the tooltip role's usage for accessible name content, but if it is used as a name, it should be used as the name, not an extra description tacked onto the name. A good example of this would be using a tooltip to expose the name of an icon button -- this is fine, and the tooltip would have a straight aria-labelledby relation to the button, or be its sole text content.

---

preventing user selection

In the Styles section, the article recommends adding this:

tool-tip {
  …
  pointer-events: none;
  user-select: none;
}

This is actually an accessibility issue as well, since several reading-related tools rely on the user being able to select text (e.g. looking up definitions, parts of speech, getting simpler language, etc.). These styles should not be added to any meaningful, user-readable text.

[argyleink]

hi y'all, author here. small reminder, i'm a solo author sharing "thinking on ways to solve" components, they're never pitched as "the way to solve it," as I find there's a consistent amount of nuance, interop and preference present in all components that make me not confident enough to label them as "best" or anything. for example, above the extra text is called noise, to me that's preference and i preferred the courteous prelude.

the goal of these is to help developers be thoughtful during UI development, learn new tools, new use cases, and be overall more considerate than they may have before (writing modes, input modes, user preferences, aria, etc). the components and show episodes have done a lot to illuminate and teach devs about screen reader technologies, testing criteria, and more. healthy considerations during ui dev, not official guidance on cross platform and AT compliance. i dont feel skilled enough for the latter, especially given the difficulty of interop between AT's.

I don't see anything in the feedback here about toggletips vs tooltips either. That was a clear distinction in this component, was to describe what it wasnt. It specifically pitches against using it as an icon label replacement, for example, but maybe that preference has more nuance than I'd thought. most of the wcag violations reported above are for what i would call toggletips, which isnt what was described in the post.

Thanks for fixing the demo link! <3

I've made a PR to update all the videos to have controls, must have been a copy/pasta error that kept travelling. good call here too.

it'll just end up being cargo-culted by developers mistakenly thinking that it's production-ready and road-tested

none of them have had this happen, fwiw. i believe this is due to how they're pitched and how the episodes play out, i'm just sharing my thinking. not a google team's thinking, or a working groups thinking.. just mine, that month i made it, with the current state of browsers and ATs at that time. this stuff is really really hard, and i'm doing my best to share healthy thinking. sorry this component isnt meeting your expectations, i'm doing the best this one person can.

[argyleink]

btw, at the bottom of each article, I share references to other thinking on the component. if y'all are willing, I'd love to feature your thoughts for others to learn from?

[aardrian]

hi y'all, author here. small reminder, i'm a solo author sharing "thinking on ways to solve" components, they're never pitched as "the way to solve it," as I find there's a consistent amount of nuance, interop and preference present in all components that make me not confident enough to label them as "best" or anything.

The title is "Building a tooltip component". The sub-head is "A foundational overview of how to build a color-adaptive and accessible tooltip custom element." That sounds very much like the article is sharing a "foundational" and "accessible" tooltip, broadly as an "overview" telling folks "how to build" it.

Also, the article lives on a Google Chrome-run site, actively trying to make itself a destination for devs (and being successful since it owns a search engine too). I would hope that either you are being paid for your content and/or Google Chrome has a team of reviewers, including accessibility experts, who would review anything with a claim to be an "accessible tooltip custom element." I posit Google has the cash. This may be why I am wary of the "solo author" qualifier.

As such, I am not beating you up with this issue. Google Chrome's web•dev editorial process has clearly let you down (whether or not you were compensated, which is none of my business).

[…]

I am dismissing the other parts of the response that are unrelated to the accessibility issues raised.

---

for example, above the extra text is called noise, to me that's preference and i preferred the courteous prelude.

I called it "verbose", not noise. I also noted it as a localization risk (item 4) and not in line with the role's guidance of using the accDesc (item 5). The developer's personal preference is incidental to the actual risk.

I don't see anything in the feedback here about toggletips vs tooltips either.

Because I was not talking about toggletips in my feedback. Everything in my feedback is based on your tooltip demo and article code.

most of the wcag violations reported above are for what i would call toggletips, which isnt what was described in the post.

The WCAG Success Criterion 1.4.13: Content on Hover or Focus failure I note (item 2) is explicitly about your tooltip implementation. I said as mucn in the phrase "The tool-tip demo as written". Also, the SC name includes the word "hover", which is the key feature of the tooltip. The demo as you have it clearly violates WCAG.

[dstmarthe]

Thanks all for raising this issue and providing insight. We’re moving to a new platform and so we’ll fix this over there. I’ve moved the issue to our new tracker and you can see it /provide more context at https://issuetracker.google.com/issues/298296173

[aardrian]

You have selectively moved follow-up comments which raise additional concerns. You did not move any that offer context on the history or lack of action from the author for nearly a year. This is important information not only for finally correcting the post but for people who may also realize there are problems and follow the "Improve article" link and end up on GitHub (or the new platform if redirected there).

You also did not link this GitHub issue from the new issue.

1. Is it your intent to delete all issues (and comments)?
2. If you are moving away from GitHub, does this mean readers can no longer file PRs to fix broken links and the like (as I did with this post)?

[rachelandrew]

Hi @aardrian

We're moving our sites to the internal platform (in common with most other Google sites) in order that our team can spend more time working on content rather than maintaining a platform for content. We'll archive rather than delete this repo so the history should be maintained.

Dale is moving issues to our public issue tracker to make sure we have an internal ref for anything that was originally here, which will be available after we go live on the new platform for other issues to be raised by the developer community. This is mostly just so my team doesn't have to work across two collections of issues for triage purposes.

There will be no way for external folks to create PRs on the new system, as it's internal to Google. However, as mentioned there will be the ability to raise issues in the tracker.

[aardrian]

Hi @rachelandrew !

I appreciate you telling me it will be archived. After I left the comment I discovered another archived repo for web•dev, so there was precedent I did not know.

I understand not wanting to maintain issues in two places.

FYI that as soon as I went to the new tracker I was met with an unlabeled checkbox to accept the ToS. My concern is the folks who might raise issues here may encounter additional hurdles plus a learning curve on the new issue tracker. I encourage Google to perform a thorough review to ensure there are no barriers. (That's not to say that GitHub doesn't have accessibility issues.)

If you see a drop in accessibility feedback on web•dev articles, that may be an indicator that the issue tracking platform itself is preventing it, not that all the content is ideal.

In the meantime, I would still love to see this tool-tip article fixed regardless of where it is tracked. It has been nearly a year since the @argyleink last responded.