Accessible Interface for Line/Area Charts

[ekh64]

This is some work I did for a project to include accessible data visualizations for line and area charts. I figured I'd bring it into Reactochart to share with the broader community.

In this PR is the interface itself, documentation, and tests.

Here is what the interface looks like. It allows users to navigate through a line/area chart with screenreaders or other assistive technology.

As this was written with a somewhat specific use case in mind, it might not be compatible with all Reactochart features (I don't, for instance, recommend using this with bar charts) and custom domains might require a little more thought to ensure we capture the data points accurately.

That being said, I do think we should include it for our consumers, and who knows, maybe one of them will have some great feedback/ideas for this.

[iezer]

This looks great @ekh64 Really looking forward to testing it out. I left a few comments and I'm happy to chat about them more offline.

[iezer]

I had this idea to simplify the API by using dependency injection and injecting the A11yInterface into LineChart so that a) the API is more declarative and b) we can be more explicit about which components support keyboard navigation. Then I realized it doesn't work for multiple line charts in the same XYPlot which is probably why you didn't go with this in the 1st place!

Still sharing for discussion. Is there any way we could do something like this and still support multiple charts in the same XYPlot?

return <XYPlot scaleType="linear" width={600} height={350}>
      <XAxis title="X Axis" />
      <YAxis title="Y Axis" />
      <LineChart
        data={data}
        x={d => d.x}
        y={d => d.y}
        lineStyle={{stroke: '#ff7f0e', strokeWidth: 3}}
        ariaLabel={(d, index_in_case_we_need_it) =>  {/* rename ariaLabelGenerator -> ariaLabel */}
        `x Value: ${d.x}, y Value: ${d.y}`
        }
        numAriaLabels={data.length} {/* Do we even need this? Could be optional and default to data.length*/}
      />
    </XYPlot>;

I'm guessing inside of LineChart we'd add something like this:

{ props.ariaLabel ?
<A11yInterface
  ariaLabelGenerator={props.ariaLabel}
  numFrames={props.numAriaLabels || props.data.length}
/> : null
}

We can even provide a sensible default ariaLabelGenerator function for LineChart and then the caller could get this for free.

[ekh64]

As I mentioned in another comment, I'd prefer to leave this as a standalone component because this would break if we were to use multiple LineCharts, or Line + Area Charts. My project leverages rendering multiple data in different linecharts, and this built in schema would not work for that use case. However if we export the A11yInterface as an optional component and do this as well, I think that would be great.

[iezer]

I really appreciate the detailed comment here.

I'm thinking of a few other ways to tweak the API here to make it more like other Reactochart functions. Why not just pass data as a prop to A11yInterface and make ariaLabel a function that takes a datum and an optional index, similar to most D3 functions? Then numFrames (which I would rename numLabels) could default to data.length and probably doesn't even have to be passed in. It seems like most of the implementations of ariaLabelGenerator need the data anyway.

[ekh64]

So I thought a lot about using data. It becomes a little more complex when dealing with multiple data sets. For example, if you have two line charts in an XYPlot, you would only want one A11yInterface, and that A11yInterface would need to account for both data sets. This makes calculating the number of frames a little complicated since data1 and data2 can be different lengths, and can contain overlapping values.

I wanted to avoid looping over the data to find all unique data points, though since lodash is a dependency here, I suppose we could find the union of x values more easily. unionBy seems promising and using Reactochart's passed in dataset prop, this could work. However, it would make generating the aria-labels a little different, since then we'd be working with the x value, as opposed to the frameIndex. This would also make the Interface more robust with data sets of unequal lengths and unequal x values.

[iezer]

Thanks for the helpful comment!

[iezer]

Thanks for adding these clear tests.

[iezer]

I wonder if we can brainstorm some better names for this component that describes what it does. There are many other parts to A11y that we might tackle in the future using different components. How about AriaLabelContainer, AriaLabelChart or InteractiveAriaLabels?

[ekh64]

Totally open to renaming, I like AriaLabelContainer

[ekh64]

@iezer Those were great suggestions, I've gone ahead and significantly changed the schema, which now takes n data with accessors datasetWithAccessor and modifies the generation to be based around the xValue rather than the index. this actually solves for cases where the data doesn't have equal domains with multiple datasets.

Let me know if you have other suggestions, as the datasetWithAccessor was a little clunky, but since LineCharts can take a unique accessor, I wanted to ensure users could support multiple datasets with different ones.

[iezer]

This variable name is a bit confusing because if I'm reading this correct it seems like d is really an xValue. Seems like ariaLabelGenerator will almost always want the array of all data points for that xValue so how about figuring that out here in order to simplify the handlers that are passed in? This line could be something like

aria-label={ariaLabelGenerator(xValue, data, index)}

where data is the array of data just or that xValue, not the whole data for the chart.

You'll probably have to change line 78 to something like this:

data.map(d => [d, getValue(accessor, d)]),

[ekh64]

My one concern is this approach could lose the context of the data. We can return the data points, but it could become unclear to the end user which data point belongs to which dataset it belongs to. For instance, I could have a schema like:

{
   name: 'Beyonce'
   data: [array of values to be rendered]
}

{
  name: 'Drake'
  data: [...]
}

In the schema I defined, that context (name) is lost when returning the two datapoints for a given xValue, and since aria-labels need to provide that context so the user understand what they're hearing, I'm not sure this is a better approach.

[iezer]

Can you give a full example with that structure? All the examples just have an array of data with no name. Isn't the same end user who's defining ariaLabelGenerator also defining datasetWithAccessor and could reasonably assume that the data points come in the same order?

[ekh64]

The issue is less with the datapoint and more with needing context outside of the array used to generate the LineChart, which currently is all that's being used in datasetWithAccessor

[ekh64]

So in the example I provided, we'd only be passing in the data attribute to the LineChart and datasetWithAccessor, but we'd want to know what name data0 and data1 belong to in the ariaLabelGenerator. The user can define this themselves if we provide the xValue, but I worry about providing the other arguments if the end user doesn't actually get value given multiple datasets. They'd have to do that figuring out themselves anyway.

[iezer]

Oh I see, my suggestion was to pass the xValue and the data (and even the index in case people need it) since I'm guessing in 99% of cases (and both your docs examples) users will want the data. So in your 2 datasets example, instead of

  const ariaLabelGenerator = xValue => {
    const data0Point = data0.find(d => d.x === xValue);
    const data1Point = data1.find(d => d.x === xValue);
    let ariaLabelString = `x Value, ${xValue}`;
    if(data0Point) {
      ariaLabelString += `, data0 y Value ${data0Point.y}`;
    }
    if(data1Point) {
      ariaLabelString += `, data1 y Value ${data1Point.y}`;
    }
    return ariaLabelString;
  }

you could have

  const ariaLabelGenerator = (xValue, [data0Point, data1Point], /* index */) => {
    let ariaLabelString = `x Value, ${xValue}`;
    if(data0Point) {
      ariaLabelString += `, data0 y Value ${data0Point.y}`;
    }
    if(data1Point) {
      ariaLabelString += `, data1 y Value ${data1Point.y}`;
    }
    return ariaLabelString;
  }

[ekh64]

Sounds good, I'll make those changes this week and update the PR 👍

[ekh64]

sidenote, I noticed some funkiness around precommit hooks and the browser tests. However running the browser tests in the actual browser pass 🤷‍♀️

[iezer]

🚢 Great work @ekh64 thanks for taking this on. Looking forward to trying it out.

[iezer]

👍 this looks great.