[Accessibility] Device Dependent handlers are used. Tooltips are not accessible with keyboard.

[puneet-ahuja]

Tooltips in the charts are not accessible with the help of a keyboard.

Steps to replicate:

Open the Codesandbox Link.

The above link opens an interactive multi-line chart.
We can access the tooltips on the lines using mouse hover but not with keyboards.

[domoritz]

Yes, that's an issue. The tricky thing is that we don't always have navigable elements since Vega can render to Canvas. So this may not be something that can be solved in general but we should look into having keyboard navigation with the SVG renderer at least.

For Canvas, we could suggest people use something like https://github.com/cmudig/data-navigator (cc @frankelavsky).

[majornista]

@domoritz I agree with you that in the same sense that aria props, like role and description, are only relevant when rendering with SVG, keyboard navigation should work within the SVG renderer. Deciding on how to implement keyboard navigation can be tricky and requires flexibility within the renderer. For example, with many datapoints in a multiline chart, you probably don't want every datapoint that renders a tooltip on hover to be included in the tab order, but instead provide some mechanism for "drilling into" and escaping back out of different levels of granularity. For example, in a multiline stock chart, you might want to focus the line for one of the stocks or indexes displayed and get a description of the general trend, before drilling in to get detail on every datapoint or trade. @frankelavsky does something along these lines in the Data Navigator demo of a stacked bar chart.

[frankelavsky]

Just hopping in here to agree with @majornista that avoiding tedious navigation would be ideal. It might be worth considering (down the road) some kind of abstract interaction layer that accessibility is coupled with, so that the SVG versus canvas versus [insert future tech here] conversation doesn't limit the design space. The navigational experience should something devs can specify but is also designed the same between rendering types. (Ideally the design isn't coupled to the tech we use to draw.) We probably need a sub-grammar for accessible data navigation/interaction.

And yeah, the default treatment of SVG + ARIA wouldn't be good to base things off of, which I discuss in the paper for data navigator and also in a vega-lite demo. The vega-lite demo uses canvas and a way to skip all the points. But making it easy to design and specify these types of navigation, to me, seems like the real challenge here for vega. (Sorry to open a can of worms potentially on an issue related to tooltips but I wanted to take a step back from this to call out what I think is the bigger issue.)

[majornista]

@frankelavsky and @domoritz Thanks for joining the conversation. I agree that if it's not easy to define these types of navigation patterns, developers won't do it. My first inclination, as someone who spends a great deal of time doing accessibility remediation, would be to dive in and try to fill the feature gaps that prevent a developer from being able to author an accessible experience, like supporting tabindex for marks, as was your original inclination in #2548, so that a developer could potentially define focus and keyboard events for marks. But, even if the grammar were to support these features, the amount of effort for someone using Vega or Vega-lite to craft an accessible experience would be still be high, and may even require defining a bespoke navigational experience for each data viz.

We should strive for something that works well for most use cases out of the box, like the keyboard accessibility for Tooltips requested in this issue, yet can be customized to support more advanced features, like making the legend behave as radio buttons, as in this Interactive Legend example.

[frankelavsky]

Yeah, sounds like a good strategy for now is:

1. reasonable defaults for most use cases
2. guardrails against bad authoring possibilities
3. (distant goal) expressiveness and control for the designers/devs who want to really do interesting and compelling things

Progressive disclosure for tabindex is a pretty standard practice for nested elements like menuitems/etc. So to me, that would probably be the most reasonable default.

With Visa Chart Components our default was that the tooltip and a chart element's ARIA were always 1:1 unless the dev explicitly broke the defaults and specified them both otherwise. This allowed us to keep 1 element navigable between a tooltip and a chart element (they were just semantically treated as 1 navigational group). But Vega/Vega-lite has a bit more flexible/open pattern for the tooltip that wouldn't work as well for this, I think. Perhaps I am mistaken though. One thing I worry about is that a screen reader user will end up navigating to BOTH a chart element as well as a tooltip, which may often just be a redundant experience.

I really don't know enough (nor have the time right now) to suggest what actual approach vega/vega-lite should take under the hood. My hope is that there is a thoughtful pattern implemented that is generic enough to be refactored or expanded on later but is also relatively low impact on existing practice.