Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(a11y): add data table for screen readers (sunburst, treemap, icicle, flame) #1155

Merged
merged 63 commits into from
Jun 10, 2021

Conversation

rshen91
Copy link
Contributor

@rshen91 rshen91 commented May 10, 2021

Summary

This PR creates a dynamic data table for partition type charts to present the data for screen reader users. There is an added row for percentages to provide more context to users of assisted technologies. In addition, the data table will provide more information on multilayer pie charts or small multiple partition charts. The partition data table for screen users can be seen when setting debug to true.

Screen Shot 2021-06-10 at 8 45 08 AM

Details:

Fixes #1154

  • Need to fix <td> for icicle/flame charts or properly disable it in this PR
  • Need to add tests for this functionality
  • Limit the number of results for a data table OR render the top N results vs limiting the data 🤔

Checklist

Delete any items that are not applicable to this PR.

  • Unit tests were updated or added to match the most common scenarios

@rshen91 rshen91 added :partition Partition/PieChart/Donut/Sunburst/Treemap chart related :accessibility Accessibility related issue labels May 10, 2021
@rshen91 rshen91 changed the title feat(a11y): add data table for screen readers (sunbursts) feat(a11y): add data table for screen readers (sunburst and treemap) May 14, 2021
@rshen91 rshen91 force-pushed the sunburst-a11y-slices branch from e5491b3 to 2acc45e Compare May 14, 2021 16:43
Copy link
Contributor

@monfera monfera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very important and nice work Rachel, thanks 🎉

I added a bunch of comments which are mostly just minor improvements on preexisting code you retained; I don't think those changes impact logic. Each is a small suggestion around one function, but together add up to much shorter logic.

As a next step, eg. next week is good too, it'd be great to hop on a short call for jointly test driving it with VO. Also, could we include Michail Yasonik in the review?

(specs, { legendMaxDepth }, trees) => {
const lengthOfResults = getScreenReaderDataForPartitions(specs, legendMaxDepth, trees).length;
// how to control how much is calculated
return lengthOfResults > 20
Copy link
Contributor

@monfera monfera May 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if 20 is good hardcoded, @markov00 might want to chime in. Also, even if it's too many, maybe the top N values could be kept, to not disadvantage the user with the loss of all items. Also, what's the harm in just doing it unconditionally for all sectors? Hopefully the VO user can "back out", ie. doesn't need to resort to hearing all the 0.1% slices before continuing with the rest of the page contents

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we really limit that, or is the user that can directly skip the content after the first top N values?

Copy link
Contributor Author

@rshen91 rshen91 May 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think the data table definitely impacts rendering performance when loading flame/icicle charts (particularly in terms of #1155 (comment)), so I wondering about implementing some sort of escape hatch if results are in the 1000s. This 20 is just arbitrary for now but I am definitely open to suggestions. 🙇🏻‍♀️

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think only rendering the top N in a data table sounds interesting! I wouldn't mind trying to implement that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@myasonik do you have suggestions for larger datasets? I see the top N being kind fo cool and just having somewhere (maybe the table caption?) say the amount of results there were?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@myasonik in line with Rachel's question, it would be interesting to know if there's a good practice for handling the current tradeoffs between accessibility annotations (DOM with ARIA labels etc.) and other goals, as I'm not currently aware of an API that would detect if a screen reader is used. The other goals include, bounded rendering time, responding page, economy of power and CPU utilization, economy with browser memory. Unfortunately the resource usage of DOM rendering is roughly 100x larger than that of DOM rendering.

Rachel I'm also thinking that maybe, reaching a cap, a "slice row" for "Other" could be created, with a single, longer text description for screen reading. While that can still be a long string, it'd establish a bounded DOM element count. DOM and general webpage performance worsens with every DOM element, even if those DOM elements do nothing.

Rachel, another important thing to do is to ensure that the table and row creation do not cause undue layout work for the browser. Depending on a few factors, table rendering speed can vary wildly. The rule of thumb is that if the columns are of fixed width, then the layouting is quite fast, but if the column widths are driven by the table contents, which I believe is the default, then it becomes a much heavier task. Let's chat about this when we look at the PR together.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was just going back through this PR and thought I'd document the outcome of this (we 3 chatted on zoom): In short, we're only rendering some subset of data at first (until a user interacts with a "load all" button) so there shouldn't be consequential impact to performance.

@rshen91 rshen91 requested a review from monfera May 19, 2021 19:39
@rshen91 rshen91 changed the title feat(a11y): add data table for screen readers (sunburst and treemap) feat(a11y): add data table for screen readers (sunburst, treemap, icicle, flame) May 19, 2021
@rshen91 rshen91 requested a review from myasonik May 20, 2021 16:00
@rshen91 rshen91 marked this pull request as ready for review May 24, 2021 20:57
@rshen91 rshen91 added the wip work in progress label May 25, 2021
@rshen91 rshen91 requested a review from markov00 June 8, 2021 17:17
@rshen91 rshen91 requested a review from myasonik June 8, 2021 20:29
Copy link

@myasonik myasonik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

Copy link
Member

@markov00 markov00 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, great work here.
I'd like to see reuse of the table/components on other charts as well whenever possible

@rshen91 rshen91 merged commit 87fd75f into elastic:master Jun 10, 2021
nickofthyme pushed a commit that referenced this pull request Jun 10, 2021
# [30.2.0](v30.1.0...v30.2.0) (2021-06-10)

### Features

* **a11y:** add data table for screen readers (sunburst,  treemap, icicle, flame) ([#1155](#1155)) ([87fd75f](87fd75f)), closes [#1154](#1154)
@nickofthyme
Copy link
Collaborator

🎉 This PR is included in version 30.2.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@nickofthyme nickofthyme added the released Issue released publicly label Jun 10, 2021
@rshen91 rshen91 deleted the sunburst-a11y-slices branch July 28, 2021 15:07
AMoo-Miki pushed a commit to AMoo-Miki/OpenSearch-Dashboards that referenced this pull request Feb 10, 2022
# [30.2.0](elastic/elastic-charts@v30.1.0...v30.2.0) (2021-06-10)

### Features

* **a11y:** add data table for screen readers (sunburst,  treemap, icicle, flame) ([opensearch-project#1155](elastic/elastic-charts#1155)) ([a1a68fe](elastic/elastic-charts@a1a68fe)), closes [opensearch-project#1154](elastic/elastic-charts#1154)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:accessibility Accessibility related issue :flamegraph Flame/Icicle chart related issues :partition Partition/PieChart/Donut/Sunburst/Treemap chart related released Issue released publicly
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Accessible sunburst graphs
5 participants