Accessibility and charts: what should it do?

[PavelVanecek]

I'm looking for your input in Recharts and keyboard controls and accessibility.

Currently, Recharts has a little bit of everything:

1. AreaChart will show tooltip on focus, and then using arrow keys left and right will go between data points. It does not wrap (so going right on the last data point, will stay on the last data point).
2. PieChart does not show tooltips but it instead focuses on the pie sector element (I guess this is because it gives a screenreader the opportunity to read a label on the sector?).
3. Vertical layout charts do not support keyboard controls (why? What makes vertical layout different?)
4. Some charts, like FunnelChart, do not support any keyboard interaction whatsoever.

I would like to unify this behaviour a little bit and fill in the gaps. I have questions and I would like to hear your thoughts or preferences on what Recharts should do:

• Should Recharts continue using arrow keys to focus different elements? Or should it use TAB?
• Should it display tooltip?
• Should it focus the tooltip, or focus the graphical item (like, Pie sector for example)?
• Vertical charts should support arrow keys left/right, or up/down?
• Which of these needs to be configurable and what options should be available?
• Is this a breaking change?

[julianna-langston]

First, just want to say that I love that you're looking at this, and I absolutely agree that we should have a coherent, unified approach to accessibility at recharts.

Also, I wish I could point to something and say "these guys did chart accessibility right, let's copy them", but that doesn't exist. I elaborated on that in this draft post for the A11yProject.

Anyway, let's go through these comments:

Should Recharts continue using arrow keys to focus different elements? Or should it use TAB?

Yes, it should use arrow keys. No, it should not use the TAB key.

If you make every element in the chart a tab stop, then a user who doesn't care about that chart has to tab through every single tab stop just to get past it. If the element is a single tab stop, then a user can just move on to the stuff they actually care about.

fyi, this practice of tabbing to a container, and arrowing between items in the container, is very common. See the WAI-ARIA authoring practices for tabs, listboxes, and toolbars.

Should it display tooltip?

I don't understand the question. Even though the accessibility code exists on the chart level, practically we're just making the tooltip accessible. Are you asking if we should display a tooltip by default?

Should it focus the tooltip, or focus the graphical item (like, Pie sector for example)?

Let's break this up between the focus indicator (something visual), and DOM focus. I think the chart should have DOM focus.

As for the focus indicators, if there's a tooltip, the vertical line of the tooltip is doing the job of the indicator. iirc, the pie chart didn't have a vertical line like that, the visual treatment of the pie chart slice provides the indication.

Vertical charts should support arrow keys left/right, or up/down?

Great question. For a keyboard-only user, I think up/down would be intuitive, but left/right would be discoverable.
To a blind screen reader user, horizontal and vertical charts look the same. So, we need to either tell the user that the chart is vertical (which now opens i18n questions), or we just support left/right arrow keys for vertical charts.

That said, we could always support both up/down and left/right for vertical charts, since we don't do anything with up/down arrow keys right now. However, if we just support left/right arrow keys, I think keyboard-only users will figure it out quickly, and screen reader users won't notice the difference.

In Chart2Music, I stick to left/right arrow keys, but that's because I use up/down arrow keys to do something different.

Which of these needs to be configurable and what options should be available?

The visuals of the focus indicators should be configurable. The information provided in the tooltip is already configurable.

Is this a breaking change?

I believe that changing accessibility from off-by-default to on-by-default is a breaking change. I'm not sure what else would count, though.

[ckifer]

Thanks for the detail! I'm pretty much in agreement with everything here I think.

Should it display tooltip?

I think the question is "should any keyboard action that triggers movement from chart item to chart item trigger the tooltip"?

Imo the answer to that is yes, if it has a tooltip and the usual action is hover then keyboard interaction should trigger it. If Tooltip trigger is click then maybe Enter should trigger?

Should it focus the tooltip, or focus the graphical item (like, Pie sector for example)?

I think the focus is always on the graphical item (once tabbed into the chart and navigating with arrow keys)... if the item lost focus then the Tooltip wouldn't show or know what to show anyways. I think this works as long as the info from the Tooltip is announced.

Vertical charts should support arrow keys left/right, or up/down?

Agreed with the above on this. I don't see a huge reason to support up/down in cartesian charts, but it might be nice for Treemap for example. Either that or Left/Right are just treated as "next item". This helps with not having to figure out which item is next too in say something like a scatter.

Which of these needs to be configurable and what options should be available?

Visuals are mostly configurable now I think with "active item" + cursor properties. The browser "highlight" for tabIndex on Pie has been a problem in the past. Maybe if we move Pie to controlled arrow key navigation this problem goes away?

Other than that I think people like to be able to set their own aria-labels on most/all dom nodes where applicable. Its just hard to figure where is the right "root node". A lot of current recharts can pass their own props like this, its just not always easily understood what svg element they actually end up on.

Is this a breaking change?

Anything totally net new is not breaking (adding support to Funnel). Enabling accessibilityLayer is, changing how pie behaves would be. Over all as long as the decisions are sounds and don't cause people more A11y violations on common scanners people would greatly welcome changes breaking or not.

[julianna-langston]

If Tooltip trigger is click then maybe Enter should trigger?

If you can mouse click on a tooltip to do something, then enter would be an appropriate keyboard equivalent. I don't think that this feature is currently implemented, but I can add it.

[PavelVanecek]

Thanks for your reply!

With the tooltip showing question - I am not certain if or how a screen reader will react to it. If there's no DOM focus on the tooltip, and the screen reader doesn't read it, then a visually impaired user won't know about it?

Perhaps the tooltip information should be included in the sector aria label by default? Or the tooltip should have some aria dynamic content attributes? Or do all screen readers just handle it out of the box and I don't need to worry?

Sorry if it's a silly question, I don't have tons of experience designing a11y in charts 😬 we would usually avoid tooltips for this reason but I don't think that's an option for chart library.

@ckifer mentioned tooling. Are there any common tools you recommend that we should include and observe the output?

[ckifer]

The tooltip area is a live region so I think it already gets announced but @julianna-langston keep me honest

[julianna-langston]

Coltin's right, the tooltip area is a live region. As the contents of the tooltip update, a screen reader will read out the new contents, regardless of DOM focus. (Live region are powerful in a "with great power comes great responsibility" kind of way.) This has the potential to get annoying if someone shoves a ton of information into the tooltip, but it's the simplest and cleanest way to provide the data to the screen reader user.

Imo, charts are one of the hardest topics in accessibility, and very few people in the world have any experience with it. Recharts is one of the few dataviz tools I've worked with that have been open to making the hard changes to make something accessible, so I just want to reiterate how much I appreciate all the work everyone's putting into it!

[PavelVanecek]

One more question, should the tooltip wrap or not? I imagine that charts like RadialBar and Pie should wrap (or perhaps all polar charts should?) but Area and Bar should not. Is this difference helpful? Or perhaps should all wrap?

[ckifer]

What do you mean by wrap?

[PavelVanecek]

If you reach the last data point, and continue pressing the arrow right key, does focus jump back to the first data point? Or does it stay at the last one? And same in the other direction.

[ckifer]

Ah yeah that I don't know - I wouldn't think it would be a bad thing? But I don't think it's necessarily required?

Once someone reaches the end they might tab out of it I'd imagine. But I'm also imagining a really large number of data points wrapping would be really convenient

[julianna-langston]

I personally prefer to have it not wrap, and instead support Home/End keys. This is for the screen reader user - since we don't indicate how many items there are, or which number of item you're on, it can be difficult for the screen reader user to realize that the value has wrapped around. Meanwhile, I don't think wrapping around adds much, besides the ability to get back to the beginning quickly (hence, supporting Home/End keys)

[ckifer]

Works for me