Tooltip don't work well with screen readers

[scottaohara]

The manner in which these tooltip are created results in unexpected verbosity and announcements with screen readers.

Testing with VoiceOver on macOS, and NVDA & JAWS + Firefox, each test announces "small help" twice. Once as an accessible name for the content they're applied to, a second time as the content the :after pseudo element adds to the DOM.

Additionally, JAWS and NVDA interpret the label of the input to just be "small help", as aria-label is overwriting the input's intended accessible name from the label element's text.

VoiceOver on macOS promotes the elements which have aria-labels to groups, resulting in unexpected VO focus stops.

For more information on how these tooltips could be revised to be more accessible, see this article on tooltips / toggle tips.

Thanks!

[finnhvman]

Hey @scottaohara, thanks for the detailed description! I will look into this, probably next week.

[finnhvman]

Hey @scottaohara, I read the article. Are there any accessible solutions for tooltips based pseudo-elements? One of the goals of this library is to be very easy-to-use. Using aria-describedby infers adding an id to the tooltip element which has to be unique, thus increasing the complexity. I would prefer implementing something more contained.

[scottaohara]

Not really, no. If you go the CSS content route then you are going to run into situations where content won't be announced properly as being a tooltip for the element it's supposed to be referencing, or announced at all in some older screen readers.

I understand wanting to keep things simple, but autogenerating IDs isn't really that hard though. And sometimes to do things properly you can't take short cuts. :(

[finnhvman]

Please keep in mind that this is a CSS only library meant to be really easy to use. Autogenerating IDs wouldn't be hard with JavaScript, but that's off the table.

Nevertheless, I made some improvements (https://github.com/finnhvman/matter/commit/f410e52f41eb67eca100cea811dead890fa1e36d). The updated version:

• does not use aria-label, instead it uses data-matter-tooltip
• does not use ::before pseudo anymore, only ::after pseudo

This results - in my opinion - a better experience, because the tooltip is announced only once, does not overtake the label, and the corresponding element is not promoted to group. The tooltip is announced, but as if it was part of the control label.

I know this is not the ideal behaviour, but with the given constraints (CSS only-ness) the responsibility of correctly using aria-describedby would be on the users of the library. I expect that off-loading this complexity on the users would generate more tooltips that are not accessible at all, resulting a less inclusive web.

I wish to use something like aria-description, or speech media type if they were implemented.

[scottaohara]

Thanks for making an attempt to make these better, @finnhvman,

With that said, if the intent is to be a CSS-only library, then I think it's worth noting that you'll never have a fully WCAG compliant tooltip solution (specifically relating to this implementation, failure of 1.3.1 and 2.1's addition of criteria 1.4.13), and it'd probably be worth mentioning that in the documentation.

And I don't say that to try and be a downer on the project. I think things like this are pretty cool and show CSS can be used to do some pretty neat things. Where I think this gets into murky territory though is when CSS-only solutions are touted as being an adequate replacement for the necessary functionality that minimal JS would provide.

Anyway, thank you again for giving this a shot, but unfortunately if the scope of this project is limited to CSS only, then again I'd say that there should be a note indicating that at least this particular component should not actually be used in production.

[finnhvman]

Thanks for sharing your concerns. I took some time to think about the problem, I made some further improvements (70813674e6764492c2d7bcb95e3dbf5b8845b87f):

• Made the tooltip hoverable
• Made the tooltip bigger on mobile devices

I understand that this is not the fully accessible solution, however I never stated that it's WCAG compliant. Users of the library can at least make the component fully compliant by adding the content of the tooltip as title to the originating component as well.

[scottaohara]

While you don't say your project is WCAG compliant, you do state:

Matter is solid. All the components are tested thoroughly to ensure rock-solid quality across all targeted browsers.

I'm just pointing out, concerning tooltips specifically, this is not a rock-solid statement.

I do think, based on the scope you've said you'd like to limit this project to (css-only), it makes sense to not state by omission, but purposefully indicate that "You're going to have to do some extra work to make some of these components fully accessible / WCAG compliant." There's absolutely nothing wrong with stating that, and I think it helps send the right message.

I would not, however, mention:

Users of the library can at least make the component fully compliant by adding the content of the tooltip as title to the originating component as well.

As if I'm understanding your intent here, you're saying someone could either double up your pattern with a title attribute, which would cause duplicate announcements of the information. Or rely on the title attribute itself, which is not considered a reliable method for promoting accessible information due to it's lack of full support for keyboard and touch devices.

Tooltips aren't easy. Though, again, I appreciate you giving it a shot.

[finnhvman]

I contacted @scottaohara to talk through the issues. The following commits were made to improve accessibility:

• 537b26f
• 0024fb8
• e22667d

As a result the Tooltip is much more accessible now.