Accessibility support: keyboard navigation

[iratherscribble]

Feature request to support functional accessibility for users with disabilities through WCAG 2.0 (meeting at least Level A, although Level AA would be great).

A lot of sites may need to comply with regulations or accessibility mandates for their user population. Organizations may also want to proactively accommodate users with disabilities to allow content to be consumed by everyone. This can influence the decision for developers in selecting particular libraries or approaches in presenting data to users.

An example scenario would be with the Americans with Disabilities Act (ADA). It would be legally considered discrimination if, as an example, a sighted employee became blind and the employer did not accommodate the employee to allow them to do their job.

This request is not really asking for ensuring entire compliance, as things like contrast ratio of colors would be the responsibility of developer creating the chart, but more looking for support for screen readers, keyboard navigation, and similar functional and structural areas.

[thedamon]

Really important for any library like this. I imagine implementing accessibility with something based on canvas would be a huge ordeal, but maybe as a less crazy alternative it could somehow describe the data in some kind of caption element

[etimberg]

There's a talk on general strategies for implementing a11y in the canvas https://www.w3.org/Talks/2014/0510-canvas-a11y/#1

I don't know what would be expected for a chart.

[christ0ph3r]

I just updated to chart js 2.0. Being able to toggle labels on line charts is a GREAT feature and I do not recall this being in 1.0. It would be very nice to be able to focus in on the chart js labels using keyboard navigation. Currently it seems like it skips the chart on the keyboard which can be a bit confusing for users who use the keyboard primarily to navigate around.

:smile:

[alshaero]

Certain elements are not accessible via the keyboard.

For example, buttons and tool tips are not accessible via keyboard, Expected result: All interactive user interface elements are expected to be accessible via the keyboard. This defect exists in IE 11 and Google Chrome v61.0.3163.100. Reference: Section 508, Part 1194.21, Paragraph (a).

[alshaero]

Text equivalent is not provided for non-text element

• Testing was performed using JAWS v17.0.2619. • This defect exists in IE 11 and Google Chrome v61.0.3163.100. Expected result: Text equivalent is expected to be provided for non-text elements. In this instance the graph must be accompanied by actual text that states the purpose of the graph element and communicate the equivalent information represented within the graph. Reference: Section 508, Part 1194.22, Paragraph (a).

[onehotprocessor]

Please work to make this accessible; there is only one other non-open source (that I know of - Highcharts) for charting capacity that tries to be accessible. At minimum, including tab index on the charts for keyboard navigation, and accessibly labeled tooltips, will be a terrific start.

Here is Highchart's accessibility documentation on the subject: https://www.highcharts.com/docs/chart-concepts/accessibility

Please allow the flow of information to be communicated to people with disabilities. Thank you.

[benmccann]

Documentation on how to make Chart.js charts accessible has been added here: https://www.chartjs.org/docs/latest/general/accessibility.html

[benmccann]

I think the documentation which was added has largely addressed this request. I'm not sure that there's a way to do more than provide developer guidance in our documentation, but am open to ideas. If there are specific technical implementations that folks want to propose we're happy to consider them

[stugoo]

Whilst the documentation addresses accessibility for screen readers, it doesn't add anything regarding keyboard navigation. Are there plans to introduce this in the future?

[benmccann]

There weren't any plans yet, but we're always open to new ideas. What elements would keyboard navigation allow you to move across? Is there a certain type of disability it would most help with? Is there a chart library that you think supports keyboard navigation well?

[stugoo]

Hey! Thanks for getting back to me @benmccann . Keyboard accessibility helps users with motor skills impairments such as those unable to hold a mouse or a stylus or those who suffer from hand tremors and couldn't accurately click or touch on something without difficulty. Generally they use a switch to select and highlight interactive elements to gain more information or activate the control.

For my particular use case, I'm thinking tooltips across data points. I wonder if you could append or generate links that coincide with the shapes in the canvas like in this example?

I believe Highcharts has keyboard navigation as part of their accessibility module, but I've not used it personally.

[fuzzzerd]

This would be a really fantastic add to the library. Keyboard navigation is crucial to accessibility efforts, and something that makes sense to be built into the library as opposed to the screen reader scenario, where tabular display of the data should be part of the consumers space.

[kurkle]

I tested keyboard navigation a little, is that at all helpful: https://codepen.io/kurkle/full/WNrwjMp ?

[etimberg]

That looks great @kurkle. I think we'll need a way to programmatically trigger the tooltips (#2850). Not sure how to do that given that we want to move the tooltip off of the chart instance.

[kurkle]

Updated the pen to show tooltips too, since we have API for that now. https://codepen.io/kurkle/full/WNrwjMp

[Ashutoshsahoo164]

Hi @iratherscribble @fuzzzerd @benmccann @kurkle Could you please give any update for this bug . When this bug will be fixed and closed . The primary bugs are not able to close due to this external git hub bug.

[kurkle]

@Ashutoshsahoo164 what are the primary bugs you are talking about?

[kurkle]

Thanks, @Ashutoshsahoo164

From my point of view those are external bugs and this is a primary feature request.

(edit: links to private repository removed)

Those links are not accessible to members outside that organization. Can you provide any specifics on what is required and still not possible?

[Ashutoshsahoo164]

Yes @kurkle , we just want that this git hub bug need to be fixed and closed.

[LeeLenaleee]

@Ashutoshsahoo164 as kurkle pointed out this is not really a bug but more a feature request.

Not verry familiar with accessebility things but you can customize the colors already for colorblind people, you can increase font size or use a different font entirely for elderly people who have a hard time reading. You can use keyboard navigation as kurkle showed in his codepen:

Updated the pen to show tooltips too, since we have API for that now. https://codepen.io/kurkle/full/WNrwjMp

So what kind of external bugs do you encounter and how are you supposing that this feature/enhancement request should be implemented in chart.js because its not possible yet with the current implementation.

[stugoo]

Updated the pen to show tooltips too, since we have API for that now. https://codepen.io/kurkle/full/WNrwjMp

This is awesome! :)

[AndrewCraswell]

I know this has been open for a long while, but I wanted to share that there is an engineer at Microsoft working within the Teams ecosystem who has been building a Chart.js wrapper that's being used by multiple teams. One of the big goals was meeting the high accessibility bar at Microsoft. Keyboard and screenreader support was added to graphs.

Storybook https://aka.ms/fluent-blocks-storybook

Github https://github.com/OfficeDev/fluent-blocks

Instructions

• User can tab between the canvas and the legend buttons
• When tabbed to the canvas, user can user left/right arrow keys to open tooltips for each graph dataset. Screenreader should read instructions for the user when focus lands on the canvas element
• Tooltips should be read by screenreaders when opened with the left/right arrow keys

Next steps

It might be worth working with Microsoft on this feature, because I think it would make a lot of sense to do the following:

• Meet with Microsoft folks and discuss the a11y requirements they've identified that graphs should adhere to. There are designers there that have insight
• Identify if maybe a dev partnership would work to transfer functionality in the Fluent Blocks library into Chart.js directly

I may be able to help with introductions if there's an interest in taking this up.

[etimberg]

@AndrewCraswell apologies for the delayed reply. I've been out on pat leave recently and not checking GitHub as much as I normally do.

Those charts look amazing! I'd be happy to chat with anyone from Microsoft would like to contribute

[brennanyoung]

I'm interested in this topic too. I recommend investigating the following:

https://github.com/w3c/aria/issues/991 https://github.com/Chartability/POUR-CAF

As I see it, there is no way around providing proper fallback content (or some other kind of text alternative).

It is possible to create a (possibly hidden) DOM tree inside the canvas fallback, with appropriate ARIA, so that the chart can be browsed using a keyboard. The most obvious kind of alternative for many data views is a proper data table. These are already widely supported across user agents and assistive technologies, with well-established keyboard navigation idioms.

Please note that "tabbing" is intended for operable content such as buttons or hyperlinks. Keyboard browsing of "Non-Operable" content tends to be handled by the assistive tech (screen reader), and depends very much on... a well-formed DOM tree (perhaps with ARIA to make things clearer).

I dare say that if Chart.js makes histograms and other such views, it should also be possible to generate a well-formed <table> element from the exact same data in very many cases. Just remember to include proper header cells!

I do believe Chart.js, rather than the content author, should be responsible for creating the table, because it would give a more consistent result. Ultimately this makes Chart.js better for all users.

Other kinds of chart (such as flowcharts or sequence diagrams) are more challenging, and there is no clear solution for them right now. But Rome was not built in a day: Offering a data table is already an improvement, for the appropriate chart types.

[LeeLenaleee]

I'm interested in this topic too. I recommend investigating the following:

w3c/aria#991 https://github.com/Chartability/POUR-CAF

As I see it, there is no way around providing proper fallback content (or some other kind of text alternative).

It is possible to create a (possibly hidden) DOM tree inside the canvas fallback, with appropriate ARIA, so that the chart can be browsed using a keyboard. The most obvious kind of alternative for many data views is a proper data table. These are already widely supported across user agents and assistive technologies, with well-established keyboard navigation idioms.

Please note that "tabbing" is intended for operable content such as buttons or hyperlinks. Keyboard browsing of "Non-Operable" content tends to be handled by the assistive tech (screen reader), and depends very much on... a well-formed DOM tree (perhaps with ARIA to make things clearer).

I dare say that if Chart.js makes histograms and other such views, it should also be possible to generate a well-formed <table> element from the exact same data in very many cases. Just remember to include proper header cells!

I do believe Chart.js, rather than the content author, should be responsible for creating the table, because it would give a more consistent result. Ultimately this makes Chart.js better for all users.

Other kinds of chart (such as flowcharts or sequence diagrams) are more challenging, and there is no clear solution for them right now. But Rome was not built in a day: Offering a data table is already an improvement, for the appropriate chart types.

I thought we did not want to do dom manipulation in the lib, and for this to work we need to do a lot of it.

Because of the flexible nature of chart.js with ability to add custom charts I dont think this is a feature we should support in the core since it has a lot of potential for a huge wave of bugs, this is something I would suggest writing a custom external plugin for that people can use

[kurkle]

A plugin doing a "proper" data-table for a chart could be made (by anyone), I think that would be a good compromise.

[brennanyoung]

sounds fair, esp if there is a design philosophy about avoiding touching the DOM. But in the interests of the longevity of the project, I would recommend facilitating "accessibility by default" - whether handled by plugin or not

[brennanyoung]

BTW there is an effort to create a scripting API for creating/manipulating the browser's accessibility tree. This would allow accessibility features to be introduced without adding any extra DOM. https://github.com/WICG/aom

[firststeven]

I started tinkering. https://stackoverflow.com/questions/75479945/how-can-i-navigate-through-chart-jss-elements-tooltips-using-arrow-keys

It will get done!

[julianna-ciq]

If anyone showed up to this thread looking for a way to add accessibility to their chart.js charts, I have a plugin that provides both keyboard navigation and interactive sonification - supporting both keyboard-only users and (blind) screen reader users. My plugin is chartjs-plugin-chart2music, and here are a few codepens showing it working:

Single line chart (registered for one chart): https://codepen.io/chart2music/pen/YzaVxPK Bar chart (registering the plugin globally): https://codepen.io/chart2music/pen/Exexegw Stacked bar chart: https://codepen.io/chart2music/pen/GRxWJZG Box plot: https://codepen.io/chart2music/pen/qBMBMeg

[msftedad]

Hi @LeeLenaleee, Can we know the ETA to fix this issue?

[msftedad]

Hi @LeeLenaleee, Can we know the ETA to fix this issue?

[LeeLenaleee]

There is no eta, you can add keyboard navigation using an external plugin as kurkle showed in a pen in this thread somewhere