Accessibility

[eenblam]

EDIT: It's possible that this could work out to be a small PR that just adds a few ARIA labels. If it seems like it would instead require breaking changes, I can look at providing these features as a fork or as a plugin.

I think dc.js could be made a bit more accessible. I have some ideas on where to start, and I'm willing to do the work. However, I'm just starting to get my feet wet in front-end, visualization, and accessibility, so I'll probably have to ping for help every now and then. At present, I'm trying to get a good look at the problem surface. Orca has been crashing for me on Linux, so I'm currently testing things with NVDA (with multiple browsers) on Windows.

Motivation

A dashboard is just a tree of some div's and svg. Adding in some ARIA attributes would make the SVG generated by different chart objects accessible to keyboard-only users (think limited range of motion) and users with screen readers.

I expect this will be straightforward for pie, bubble, row, and bar charts. I don't see a way to provide similar functionality to line and area charts. However, just getting this sorted out in the former case would be a big win for both visualization and accessibility, as dc.js would provide a write-once, accessible interface. (I'm not aware of this functionality elsewhere, but I'd be happy to learn that another project has already implemented something similar!)

Requirements

1. The chart must be easily traversed with the keyboard (I suspect switch interfaces should be able to benefit from this functionality without any additional work, but I haven't tried this yet.)
2. The underlying data from which the chart is generated must be available and clearly identified.
3. Presentational nodes, in particular those with .axis, should be obscured with aria-hidden="true".

Item 1 is where I'm having the most trouble getting browsers to be consistent with their accessibility API. See this table on HTML5 accessibility across browsers. This accessible implementation of jQuery UI is a good reference for the desired functionality, but their implementation has a lot of additional DOM manipulation going on as keyboard focus changes. That would probably be better suited as a plug-in for dc.js, and I would like to avoid that if possible.

Item 2 is partially solved by the existing title tags, which provide the data as label: value. The task, then, is to direct the SR to this tag. aria-labelledby might work here, but I'd like to avoid generating a unique id for each title.

Item 3 seems self-explanatory. Hide stuff that only provides visual cues to sighted users from the screen reader and keyboard, and make the data more explicitly available on keyboard focus (see 2).

Bonus Points

I'd like to establish idioms in documentation and examples for library consumers to use in structuring their content. Some things would be best implemented in the library. Other things must necessarily be done externally. I can add some specifics as time allows.

Anyway, I'll start with proof-of-concept. I'll report in next with bl.ocks that start with the base chart, then add in accessibility features with revisions. If anyone has any thoughts in the meantime, I'd love to hear them!

[gordonwoodhull]

Good stuff.

You'll probably have to work at the leaf level, on concrete charts, since not very much of the actual generation happens at the base level. Start with an easy one, see how disruptive it is.

If it can be put under a flag, that's one way to avoid breaking interfaces/behavior.

[gordonwoodhull]

Implemented in #1738 and released in 4.2.0