Web Accessibility for Complex Images

[mgifford]

I'd like to see some movement to make the complex images and complex interactions available through d3 to be accessible.

https://www.w3.org/WAI/tutorials/images/complex/

[mbostock]

What did you have in mind? It would be difficult to do this automatically with a low-level graphics API like d3-shape, and if it were possible, it would make more sense to generalize it to the Canvas or SVG APIs to automate image accessibility. On the other hand this may be possible with a higher-level visualization API that understands the semantics of the image construction, say Vega Lite.

[mgifford]

This is just exploratory for me at this stage. Looking at things like: https://apps2.neb-one.gc.ca/dvs/app_iframe.html?page=landingPage&language=en

Where I'm not sure which are problems with the library up-stream vs their implementation.

Still government should be able to use tools like d3 to effectively convey information.

Providing longdesc options are one thing https://www.w3.org/WAI/tutorials/images/complex/#providing-a-link-to-the-long-description-via-longdesc

Encouraging authors to write descriptive texts and include figure/figcaptions so that you aren't leaving the user to guess what the author intended the user to see.

Ensuring that the navigational elements are all properly accessible without a mouse.

There's lots that can be done, before looking at https://www.w3.org/TR/ATAG20/

Supporting good color contrasts...

[mbostock]

These all sound like good ideas. As this discussion is neither a bug report nor a specific feature request for this library, I am closing this issue. If you have suggestions for API changes, please let me know and I will reopen. If you seek people to help with this task, or for a discussion on this topic, please consider the d3-js Google Group or joining the d3-js Slack. Thank you! 🤗

[mgifford]

I do understand @mbostock sometimes hard to know where to jump into a new community. Thanks for pointing to some places to start.

As far as whether this is a bug, if you're excluding 10% of people from engaging with the graphs, I think most folks would consider that a bug.

[curran]

Just curious, where does the 10% figure come from?

[mgifford]

Well, that's a very conservative number if you just go by the census: https://www.census.gov/newsroom/releases/archives/miscellaneous/cb12-134.html

That said, of the 19% listed there, many will have no problem accessing d3 because they use a mouse & have good vision. But I don't think that 19% includes people who are color blind (that hits 5% of men): http://www.color-blindness.com/2006/04/28/colorblind-population/

There's also a fun list here of people who face barriers on the web which we often overlook: https://the-pastry-box-project.net/anne-gibson/2014-july-31

The population of blind users is really small, but the population of people facing barriers on the web is definitely significant.

[PatrickKing]

Hi @mgifford and @mbostock

I'm one of the authors of the linked visualization at the NEB. I just wanted to chime in and say that accessibility is a definitely on our radar, and a requirement for pages on Government of Canada sites in particular. We'll be rolling out an update with some pretty significant accessibility improvements to the tool in the medium term.

Like @mbostock said, given D3 deals with low level concepts like shapes and lines, it isn't really possible to make the tool 'accessible by default'. But there are standards for making accessible sites and webapps, and I hope to find the time to write up how I've applied them to our D3 based visualizations.

[mgifford]

Hi @PatrickKing - sorry for the delay. I was away at DrupalCon presenting about accessibility.

I'm happy to hear about the accessibility improvements. Hopefully some can be contributed back to the d3 community. One common problem is improper application of WAI-ARIA. It is usually better to try to see that semantic information is conveyed through HTML5.

It is worth looking at ATAG 2.0 guidelines. There are ways to allow for accessibility in many systems. Even just allowing the capacity to provide a title field in an SVG image. More importantly though it is probably providing space to give a textual description of what the image is attempting to convey. This can be semantically conveyed through figure/figcaption in HTML5.

I don't know d3 well enough to know how these ideas can be bought into this project so will defer to @mbostock and yourself.

[brennanyoung]

I work extensively with accessibility, and can report that accessible data views are a significant unsolved problem, and will be an area where we can only expect an increased legal pressure for solutions in the near future.

If your work is intended for a public sector audience, you need to be on this already now, and a steady uptick in lawsuits within the private sector has become evident in recent years. The d3 community should be in no doubt that accessibility concerns will come to loom very large amongst any other priorities it might have.

Alas, the standards (such as Graphics ARIA) are lacking basic recommendations, such as whether a data view is an operable or a browsable artefact. (This distinction is rather central to good accessibility of web content, but clearly, data may be either or both). We also lack non-visual idioms for navigating and interacting with data in ways that allows the implicit message to be communicated without being 'drowned out' by the individual values of each data point. Very often the individual values are noise, rather than signal. It is the "big picture" we hope to get across.

I would therefore advise that one of the first goals should be to consider how a datapoint can best be 'tagged' with relevant 'story telling' characteristics. (The forthcoming aria-description attribute shows strong promise in this area, but is not standardised yet). It is often far less important to communicate that a given datapoint has value X, that it is to know that "X falls outside/inside some limit". We need ways to express things like "these datapoints correspond in some way", "these are outliers", "these are within range" etc.

Such characteristics are precisely what makes a data visualisation more effective at 'telling the story' than a table of data (which may already be announced by a screen reader, but is often a very poor alternative). If we could somehow formalise how these relationships can be expressed in ways which can be remediated across a range of output devices, and if we can arrive at some sensible idioms for keyboard interaction with that data, we begin to approach a viable solution space for this challenge.

I don't even know whether it's the business of a library such as d3 to attend very deeply to these matters, but it should certainly do what it can to facilitate them, according to the content authors' intentions, and preferably, without producing code that violates ARIA and other relevant standards.

Additionally, some documentation and recommendation for choices of color, contrast and font could help d3 users make sensible choices. There are a handful of specific WCAG success criteria which are especially likely to be violated by data visualisations (I can pick out Non-Text Content, Use of Color, Contrast, Headings and Labels, Info and Relationships, Meaningful Sequence etc. just for starters) so it would be wise to consider how d3 might 'nudge' users to consider these particular criteria as they use the library, perhaps providing sensible defaults where appropriate.

I would advise any interested parties to take a look at https://github.com/Chartability/POUR-CAF - a set of accessibility guidelines for data views which set an intentionally high bar, going much further than WCAG. You can use these guidelines today to assess the extent to which your data views are accessible.