-
Notifications
You must be signed in to change notification settings - Fork 121
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
Conversation
e5491b3
to
2acc45e
Compare
There was a problem hiding this 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?
src/chart_types/partition_chart/layout/utils/group_by_rollup.ts
Outdated
Show resolved
Hide resolved
src/chart_types/partition_chart/layout/utils/group_by_rollup.ts
Outdated
Show resolved
Hide resolved
src/chart_types/partition_chart/layout/utils/group_by_rollup.ts
Outdated
Show resolved
Hide resolved
src/chart_types/partition_chart/layout/utils/group_by_rollup.ts
Outdated
Show resolved
Hide resolved
src/chart_types/partition_chart/layout/utils/group_by_rollup.ts
Outdated
Show resolved
Hide resolved
src/chart_types/partition_chart/layout/utils/group_by_rollup.ts
Outdated
Show resolved
Hide resolved
src/chart_types/partition_chart/layout/utils/group_by_rollup.ts
Outdated
Show resolved
Hide resolved
src/chart_types/partition_chart/layout/utils/group_by_rollup.ts
Outdated
Show resolved
Hide resolved
(specs, { legendMaxDepth }, trees) => { | ||
const lengthOfResults = getScreenReaderDataForPartitions(specs, legendMaxDepth, trees).length; | ||
// how to control how much is calculated | ||
return lengthOfResults > 20 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. 🙇🏻♀️
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…legend width calc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
There was a problem hiding this 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
🎉 This PR is included in version 30.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
# [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)
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.
Details:
Fixes #1154
<td>
for icicle/flame charts or properly disable it in this PRChecklist
Delete any items that are not applicable to this PR.