IssueTracker

The copied issue does not convey that:

• this was originally opened October 29, 2022 as content: Tool-tip post has problematic accessibility info #8959;
• as of today it has 46 thumbs-ups on GitHub;
• it received a series of comments raising additional issues (though it pasted them in, unattributed);
• the author appears to have abandoned it 10 months ago (no edits, no follow-ups) as of today.

I also see no way to tag the assignee (author) to keep the needed corrections for the problematic accessibility of the article on their radar.

patrickhlauke commented on Oct 29, 2022 with 8 thumbs-ups:

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 commented on Oct 30, 2022 with 12 thumbs-ups:

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:

  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.

rachelandrew assigned argyleink on Oct 31, 2022

argyleink (contributor) commented on Oct 31, 2022:

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 (contributor) commented on Oct 31, 2022:

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 commented on Oct 31, 20220 with 7 thumbs-ups:

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.

mjbp mentioned this issue on Nov 8, 2022

Tooltip pattern stormid/ui-patterns#52

devnook added the content label on Jan 9, 2023

dstmarthe commented on August 31, 2023:

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

dstmarthe closed this as completed on August 31, 2023

aardrian commented on August 31, 2023 with three thumbs-ups:

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

It has now been a year since this bug(s) was raised. It encodes WCAG failures and as a result opens up legal risk for anyone who follows the advice in this post.

Is anyone going to address this?

I am fine continuing to warn devs and clients that this article cannot be used as-is and let them decide how that reflects on the rest of the content on the site. I had hoped Google's regular statements about its commitment to accessibility would not make that necessary nor put its primary developer relations site at odds with that message.

Any movement on this? I still see no corrections.

I see the author is promoting another, newer "accessible" tool-tip component on the Chrome for Developers YouTube channel: https://www.youtube.com/watch?v=ASb9vO3ARHo

Is there any chance that Google or Chrome or whomever is in charge can get him to update the post covered by this issue?

The new technologies he covers in the video are nifty when they work, but many sites will need to wait a while for support and in the meantime the article this issue references is still promoting guidance that creates legal risk for those who follow it and barriers for real people.