How to add role and aria-label to canvas tag

At present, when I move to a canvas tag using screen reader, I can’t get any particular information.
Therefore, I would like to provide some information by specifying a role and an aria-label for canvas tag.

How should I specify the role and aria-label?
Alternatively, if I need to add a feature, I would appreciate advice on which implementation I should modify.

2 Likes

Hi @hassaku Thank you for the topic, as this is a very timely question. I have some bad news, as well as some hopefully better news to report.

First, the bad news is that there is not currently any API or facility in Bokeh to add Aria labels or other metadata to Bokeh output. Bokeh output is HTML + JS so in principle the DOM content of Bokeh output could be modified outside Bokeh, I don’t have any specific workarounds to suggest in the immediate term.

The Bokeh core team has recognized this as a deficiency and an important area for improvement. We are just finishing a grant proposal that would include a large amount of funding for improving accessibility over the next two years. Assuming our proposal is selected, it will cover:

  • Accessibility audits at the start and end of the grant period by Chartability, and ongoing advice and recommendations from them throughout the grant period
  • A full time developer to work on accessibility issues and recommendations for the grant period

The sorts of things we already have in mind to accomplish are

  • Ability to add Aria tags and other accessible metadata to Bokeh output
  • New APIs for accessing plot/data summary information to include in the metadata
  • Fixing broken navigation for toolbar buttons and widgets
  • Revamping color usage across all our web properties with color-deficiencies in mind
  • Support for right-to-left text in Bokeh output
  • Add new tools and make improvements to existing tools to support increased accessibility.
  • Extensive editing of documentation to use simple sentence structures that are more accessible to non-native English readers

As well as other tasks or improvements identified in the audits.

Our initial letter of interest was already advanced, and we will submit the final proposal next week. We have some amazing outside help with the proposal, and a good team effort in crafting it. I am cautiously optimistic that our proposal will be selected, in which case work will begin a little later this year.

If our proposal is not selected, these are still important tasks, but the work pace will be resource constrained by what can be accomplished by current core-devs in their personal outside-work time, unless new volunteer contributors decide to add their time and effort.

We will know the grant selection results in a few months, and will announce those here as soon as we know. Either way, there will definitely be issues on the tracker in the near future, and I would very much appreciate your valuable input on details and prioritization, or PRs if you are interested and available to contribute at that level.

1 Like

Hi @Bryan
Thank you for your reply. :grinning:

Bokeh output is HTML + JS so in principle the DOM content of Bokeh output could be modified outside Bokeh

Yes, I can do that experimentally, but in environments where the results are displayed in an iframe, such as jupyter notebook, I can’t use the way to change it from the outside.

The Bokeh core team has recognized this as a deficiency and an important area for improvement.

I think it is a very exciting activity. I am looking forward to its further development.

On the other hand, for the following project I am working on, I would like to take some workarounds, such as giving roles to canvas, in order to proceed with the proof of concept in the near future.
Do you have any advice on which file to start looking at when considering a pull request?

https://hassaku.github.io/DS-and-ML-with-screen-reader/

I can point you at where he canvas is rendered in the code, which is here. But unfortunately, the BokehJS Canvas objects are currently implementation detail, and don’t yet have a direct mirror in the Python API. This means technical decisions will have to be made, and their trade-offs considered, in order to make them configurable in any way from Python. I would suggest first opening a GitHub development discussion to plan and discuss details in order to make sure that technical decisions now do not foreclose any future options (e.g. other parts of the grant work, in case it is selected).

Regardless, I also have to make sure that expectations are set regarding possible timing. Something like this would go in one of our larger feature releases, which is at least a few months off.

Thank you very much for your advice on the procedures.
If it is possible, I would like to proceed in that way. :blush: