Re: [csswg-drafts] [css-ui] Standardize tooltip styling and expose as `::tooltip` (#8930)

There was one aspect that I want to re-iterate: a concern for the accessibility of the current native tooltips (the title attribute, etc.)

(The only comment in this issue where this was brought up — https://github.com/w3c/csswg-drafts/issues/8930#issuecomment-1581657010 — by @Westbrook)

One of the concerns developers have when they implement custom tooltips is having to follow accessibility guidelines.

The issue is that the current `title` tooltip **does not** follow these guidelines either.

What I'm talking about is the WCAG “Content on Hover or Focus” — https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html, particularly the “Hoverable” criterion:

> If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

There is an exception:

> Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

However, if we allowed styling the tooltip, I'd argue that at this point, this exception would stop being applied.

Tooltips not being hoverable (and their text not being selectable) is one of the reasons developers could continue using custom implementations.

However, interestingly, there is one aspect of the `title` tooltip that _cannot_ in any way be currently implemented with just CSS without JS — the “Dismissible” criterion:

> 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;

Native tooltips can be dismissed by `esc`.

There are no ways in CSS to achieve this. Any custom implementation would require JS to make tooltips dismissible. Though this is a rather separate issue (I'm planning to eventually open up a separate issue), I think it is worth it to bring it up here, as _if_ the new `::tooltip` could be made to conform to the other criteria, it would be awesome.

- - -

That said, as an author, how would I want a `::tooltip` to behave:

1. I'm 100% fine with it being visible only inside the page's viewport and never going outside of it.
2. I would say that if the `::tooltip` is defined, ideally, we should remove the default UA behavior completely and add a new pseudo-element that would behave according to all the CSS rules without any additional UA behavior.
3. It should still have to be dismissible, and I would prefer this to be a mechanism available in CSS for anything else as well in some way (my draft idea that I wanted to create an issue about — make `esc` remove the `:focus`/`:focus-visible`/a new `focus-…` pseudo-class from the currently active element).
4. It should be selectable. A related issue that was also discussed recently — https://github.com/w3c/csswg-drafts/issues/8892 — as this element would be a pseudo-element, browsers would have to support text selection of its content.
5. It should provide enough default affordance (either by default styles, and/or by delay before hiding), making it possible to hover over the tooltip while moving the cursor over it slowly.
6. It should be possible to trigger this tooltip from the keyboard, potentially when focusing the element with the `title`.
7. I probably forgot something else — probably a lot.

Until a `::tooltip` would eventually check all these boxes (I'm totally ok with things being implemented iteratively), authors would continue relying on libraries and custom implementations.

-- 
GitHub Notification of comment by kizu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8930#issuecomment-1644631295 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 20 July 2023 21:28:42 UTC