Accessibility: Make charts screen-reader-accessible

[cjcenizal]

Alt text

The chart or visualization should have alternative text that conveys the type of visualization and some information (e.g., "Bar chart showing @timestamp per hour"). One way to present this information is with aria-label, which you are already using throughout the site to provide information to screen readers.

Spy

The spy allows the user to view data that was used to generate the report, which is good, but the tables it presents has some accessibility issues, including the following:

• The "Table/Request/Response/Statistics" options should be marked up as an ARIA tab panel (see https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel for details)
• The table's sort icons aren't keyboard-accessible.
• The "Export Raw / Formatted" links at the bottom of the spy aren't keyboard-accessible.

Tabular version of visualization data

Every visualization and chart needs a tabular version of this data. This can be either accessible via the UI or hidden off-screen so that only screen readers can access it.

Hide axes

Text that is part of the chart (e.g., x and y axis) that is not useful for a screen reader user should be hidden. One way to do this is with aria-hidden="true". Note that if an element can receive keyboard focus, it should never have aria-hidden="true". The links will still receive keyboard focus, but the link text will not be read.

Relevant ARIA spec: 1.1.1 Non-text Content - Level A

[timroes]

Making the charts screen-reader accessible might be one of the hardest tasks, and there might be more complex solutions to find in a long term. Having the data as a plain table, might be a start, but a table is still quite hard to navigate with a screen-reader without losing context ever so often.

Some ideas for more complex, but maybe more accessible solutions, that we could think about in the long run:

Interactive keyboard navigation

If coming over a chart, you have the possibility to enter it's interactive mode. In this, you can use arrow keys to navigate. Some examples for different chart types:

Pie chart You just use up/down to get a list from the largest slice to the smallest slice and you get automatically read the value and percentage, example screen-reader reaction:

1. Most used browser, pie chart [with 2 levels]
2. Enter the interactive mode
3. Chrome, 75% down
4. Firefox, 13% down
5. Edge, 5% right [to jump to nested level]
6. Edge 14, 3%, 60% of Edge down
7. Edge 13, 2%, 40% of Edge left [leaving level]
8. Edge 5%
9. ...

Similar interactive modes could be build for 2 dimensional charts, like a bar chart, where left/right moves the cursor on the x-axis and you get a readout of the x position and the y value, and pressing up/down may jump between different lines.

Auditive support

Even with a complex, satisfying interactive keyboard mode, some charts are hard to get a feeling for the overall picture (is the line rising or dropping). Never seen something like that and now sure whether or not that might be really helpful, but auditive support might give that. Imagine, that while navigating on the x-axis as described above, won't read you out immediately the value, but you get a sound, for the value, which pitches changes with the y value. That way you can hold right and get a good feeling immediately how the data develops over time, without seeing it. And if you need the concrete values, just pause at a specific position or press a specific key to read out the value.

For that kind of implementations the Accessible Object Model might become handy. Until now we can utilize ARIA live regions for that.

I know that these options are not a short term goal and easy to develop, but we might already think about that kind of long term goal what we actually want to do with the charts, and how these will look in our utopian perfect accessible Kibana :-)

[timroes]

I moved this to phase 2, since this will require some more thoughts and discussion. Phase 1 now only holds showing a warning: #13572

[myasonik]

Just to leave this ticket with a more firm plan, for now, I think it's important to focus on simple solutions we can execute on today. So, where you started with - having a plain table backing all visualizations - I think is a great plan.

Once we have a base line experience in place, we can spend more time iterating on possible solutions to improve that base line but something is better than nothing.

Related: #22142

[elasticmachine]

Pinging @elastic/datavis (Team:DataVis)

[elasticmachine]

Pinging @elastic/datavis (Feature:ElasticCharts)