Skip to content
This repository was archived by the owner on Mar 14, 2024. It is now read-only.
This repository was archived by the owner on Mar 14, 2024. It is now read-only.

content: Tool-tip post has problematic accessibility info #8959

@aardrian

Description

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

Metadata

Metadata

Assignees

Labels

contentIssues related to contentcontent updatefor issues that do not require new content (only for updates to existing content)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions