Tooltip triggers are inaccessible to keyboard users

[aardrian]

Using the Accessibility page from the latest (2023) survey, the tooltip triggers are inaccessible to keyboard users.

Because they contain click handlers, NVDA users in particular will hear "clickable" for every node using this construct. This happens even though they cannot trigger the tool-tips and the node itself may have no text to convey. On this page, an NVDA user has to hear "clickable" at least 105 times. Use this XPath to confirm the count:

//div[contains(@class,"Tooltip__Trigger")]

I encourage you to move away from JS event handlers and lean on :focus style triggers by default, adding in :hover when the :focus has been built.

[SachaG]

To me it makes sense that a button should reveal its tooltip when focused. But if I made every tooltip on the page focusable, wouldn't that include a lot of non-interactive elements and slow down keyboard navigation a lot? I guess that's better than the info not being accessible at all?

On a technical level, I'm using Radix's tooltip component, so I'm not entirely sure if those issues come from them, or if I implemented something poorly (or maybe have an out-of-date version). I'll look more into it.

[aardrian]

To me it makes sense that a button should reveal its tooltip when focused. But if I made every tooltip on the page focusable, wouldn't that include a lot of non-interactive elements and slow down keyboard navigation a lot?

Yes, if a button has a tool-tip, then it should be revealed on focus as well as hover. Bear in mind that you still need to programmatically associate them since a blind screen reader user won't see these tool-tips at all. Radix does this by dynamically adding aria-describedby, which is weird since SR users can put focus on a button without triggering that script (try it, perhaps with NVDA by pressing B on the Radix example).

I am not suggesting making the tool-tips focusable, however. If the tool-tips have focusable content, then they need to become disclosure widgets (pop-up isn't quite there yet for support).

All that being said, note that my selector above is looking at <div>s. Let me amend the selector to show <div>s without tabindex (so they cannot take focus at all, meaning a keyboard user cannot trigger the tool-tip):

//div[contains(@class,"Tooltip__Trigger")][not(@tabindex)]

Same number of keyboard inaccessible tool-tips.

In short, if it has a tool-tip then it has to be keyboard focusable. 99 (at least) nodes are not.

On a technical level, I'm using Radix's tooltip component, so I'm not entirely sure if those issues come from them, or if I implemented something poorly (or maybe have an out-of-date version). I'll look more into it.

Radix built it off an unfinished APG proposal. Bear in mind that the ARIA Authoring Practices Guide is not a spec. Its patterns are not fully tested. Its patterns all have warnings on them because I fought to get them added. That pattern even notes it is a work in progress. As such, I am not surprised it is using a pattern it did not fully vet because 12 seconds of testing showed they probably did not.