a11y: tooltips interact badly with voiceover

[cscheid]

See report on https://github.com/journalovi/2023-park-gatherplots/issues/10

[cscheid]

@domoritz pinging you here. Just to make sure I understand the issue:

Is the problem you're describing that when you're navigating the document with the keyboard, the tooltip fires off inadvertently?

If that's the case, I'm trying to figure out how to determine from our side that the navigation is happening in a voice-over context, or if there's a global setting that signals to us that a screen reader is enabled.

@jooyoungseo Do you know more about this?

[domoritz]

Yeah, when I navigate a document with a screen reader on (so not just keyboard navigation) the tooltips open and then I navigate into the tooltip. I'm happy to show you on a video call.

There shouldn't be a setting to recognize whether a screen reader is used because it's bad practice to give screen reader users a different page (it's a web design principle).

[frankelavsky]

I have a few opinions about tooltips just from some experience, so take this with a grain of salt too (as it's only a semi-informed set of opinions):

• If the tooltip information is small enough, put it into the alt text for that element. The tooltip can then just be thought of like a visually accessible version of the alt or vice-versa. We did this as a default in VCC.
• If the tooltip is complex (lots of text or entirely new elements, like additional charts, UI elements, etc), provide ample information beforehand and then give a keyboard shortcut to optionally jump to whatever the currently open tooltip is. The same key can be used to jump back to the last element they were on. The downside to this approach? Not great on mobile (or is complex to handle). But tooltips are often treated differently on mobile anyway, so this is really design-context dependent.
• Another alternative is to render tooltips like a child of the element they represent, in the same way a menu contains menu items. This would allow native SR controls to optionally disclose/explore the tooltip but also skip over it too. However, you really should have a substrate of pure HTML or use something robust like data navigator for this. Trying to make menus in SVG accessible is pretty rough. I did a bunch of technical experiments on this and the space of support still doesn't look great as of 2021 (perhaps better now).

One issue with tooltips is that in latest standards they must be handled with a bit of rigor. This thread is largely concerned with SR access, but tooltips are notoriously difficult for other folks as well (think motor/dexterity disabilities and target size, for example). Also, for creating a dismissable tooltip, escape key is considered a common convention.

There are other opinions I could bring up for more nuanced cases, but generally I look at those 3 options. Know that there are longstanding experts in the accessibility world who have made some serious cases against many of the most common tooltip designs. It's worth at least reading up on those as well to get a sense of your design justification here.

[cscheid]

Thanks for the input, and it all makes sense.

Unfortunately, we need to navigate this somewhat carefully on our end because we have a long-standing policy of not regressing or removing existing behavior. I want to ensure we do the right thing wrt a11y, but we need to think carefully about how to go about it.

[frankelavsky]

Oh, absolutely understand that. I figured that if I was going to chime in, I'd just let you know the whole suite of it.

I am not sure what tooltips do presently for you and what would be considered breaking/regression, but I'd at least consider making tooltips optionally skippable in some way but easy to access when needed.

[cscheid]

I'd at least consider making tooltips optionally skippable

That's already possible to do by adding the following to your yaml front matter:

citations-hover: false
footnotes-hover: false
crossrefs-hover: false

[frankelavsky]

So in the case when tooltips are present, screen reader users are able to skip them?

[cscheid]

So in the case when tooltips are present, screen reader users are able to skip them?

No: those options disable the rendering of the tooltips entirely. Your question of how to skip them is the question I posed at this comment just above, to which Dom and you responded. So now I'm a bit confused at what your point is.

[frankelavsky]

Sure, I was just reiterating that even if you don't want to regress, I would consider adding an option to make tooltips optionally skippable even when they are rendered. As in, don't hide them from screen readers entirely, but allow SRs to access them outside of their primary navigation path. Apologies that I've just complicated things.

[domoritz]

That sounds like the best solution to me. Make it so that tooltips are not in the primary navigation path for screen reader users but so that they can navigate to them.

[cscheid]

Make it so that tooltips are not in the primary navigation path for screen reader users but so that they can navigate to them.

What does that mean concretely in terms of the DOM structure?