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 <tool-tip> 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 <tool-tip> inside of a <picture> 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 <tool-tip> and we can add our own prompt text for non-sighted users.

Not all screen reader users are blind.
CSS generated content will not translate via automated tools.
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).

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.