Add Accessibility support for charts.

[mlvea]

Currently graphs are not accessible to VoiceOver and other accessible technologies.

[danielgindi]

A PR is welcome :-)

[liuxuan30]

What does the support looks like? curious

[graesser-tiaa]

See this example for using alt tags to add accessibility support to a web page - http://accessibilityresources.org/joomla/index.php/blog/alt-attributes-it-s-not-that-hard The blog post shows what to do for a bar chart.

[pauljadam]

If you want to see what an accessible chart looks like on iOS just view the Stocks app from Apple it's got VoiceOver Accessibility for data points.

https://pbs.twimg.com/media/DOR8G6lVQAEQ7Hi.jpg:large

I found this chart library because they're using it at work and it's not accessible. Can you copy the Apple stocks implementation?

[mathewa6]

Hello!

Thanks for the great library. I'd be happy to try and tackle this issue for as many chart types as possible, so feel free to assign it to me.

While I'm working on it, does anyone have any resources or recommendations for what the Scatter and Combined chart should sound like to a VO user? Right now I'm leaning toward a axis based range summarization (For eg, the sample scatter plot would sound like "0 to 10, DS1: 9 points from 81 to 99, DS2: 5 points between 50 and 87... etc"), however as you can imagine in these two cases, it can be an auditory overload given enough categories.

The other option is to simply let the creator describe the visual. But in that case should the description be a required property? This might not work as well for charts with dynamic data.

There is also the option for simply narrating a table of values, but usability wise, I think that is a poor choice, since the point of a visualization is to make the information contained palatable.

As of now these (and variants) are what I'm working on:

• [x] Line
• [x] Bar
• [x] Pie
• [x] Bubble
• [x] Radar

[pmairoldi]

Thanks for looking into this @mathewa6. This resource might help you. It’s for the web but the same ideas apply https://www.w3.org/WAI/tutorials/images/complex/

[mathewa6]

@petester42 Thanks! I hadn't considered splitting descriptions so that is very helpful.

iOS/tvOS allows for a little more interactivity and that way, most folks who use this library will get accessibility "for free" based on titles and legends already provided, without needing to manually add descriptions.

Multiple descriptions sounds like it'd be a great way for static scatter/combined plots or even on macOS for static plots.

[pmairoldi]

At least for the web the idea of having multiple descriptions is for the user to be able skip I if they don’t care. It’s pretty bad experience to read an entire graph without user consent.

[mathewa6]

Absolutely.

iOS/tvOS let you browse by Header using the VoiceOver rotor. I'm making sure to make the first element of the graphs a Header item (which uses the existing title/legend/description), so they can just skip to next header if they're not interested.

Then again, since Charts is cross platform, let me know if you'd prefer a description on all platforms as primary.

[pmairoldi]

Rotor is also supported in the latest version of macOS. I think it’s fine

[mathewa6]

Awesome! Thanks for bringing this up: worth getting these sorts of issues out the way before a PR imo.

[mathewa6]

@petester42 I've updated NSUIView so that iOS and tvOS now use UIAccessibilityContainer with the first element being a header, whereas macOS uses NSAccessibilityGroup, while still keeping the first cell/row a static text element (i.e VoiceOver (VO) will skip right over the chart, only providing a label, unless the person is interested enough to enter the group). I think this will allow for the option of adding a secondary detailed description as that first element for macOS, while keeping with platform conventions wrt screenreaders.

[mathewa6]

Quick question:

I had a couple VO testers use the sample Radar chart I was working on and we ended up with equal preference for two different ways of parsing the data. I thought I’d ask here, in case there is some statistical or common use case for the chart type that makes one particular method easier. Basically, for the Radar chart, we can present the data in two ways:

• By data set (in which case we sort by decreasing order of value, otherwise the clockwise arbitrary order made little sense to our VO users)
• By variable (in which case we are comparing the value across datasets)

Here’s a 30s video demonstrating the difference.

Is there a preference on the library's side for these ordering based on how the Charts library is used and/or intended to be used?

If not, I will use the first method, since it seemed to make more sense initially to our blind colleagues.

[mathewa6]

Submitted PR #3520. I've left some verbose comments to explain what's happening and workarounds etc. Let me know what needs to be changed. 😊

[SaiPasumarthy]

@mindgraffiti Does anybody looking at Dynamic Type Support for Chart Labels?

[mindgraffiti]

@mindgraffiti Does anybody looking at Dynamic Type Support for Chart Labels?

Hello Sai,

Sadly, no. This task was de-prioritized and there are no plans for Woo Mobile to work on it.

[lingzlu]

Accessibility support request: is it possible to include the capability for a custom accessibility value that differs from the displayed axis label? I'm working with bar charts containing string values as axis labels. To ensure proper chart rendering, I had to truncate long axis labels to a certain length using a custom AxisValueFormatter implementation. However, for the accessibility value, I want it to announce the complete label string.