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

[Monitoring] Address multiple accessibility issues #20619

Merged
merged 18 commits into from
Aug 8, 2018

Conversation

chrisronline
Copy link
Contributor

@chrisronline chrisronline commented Jul 10, 2018

Fixes #20191
Fixes #20190
Fixes #20189
Fixes #20188

Summary

This PR addresses multiple accessibility issues in monitoring, all related to optimizing screen reader experience.

One visual change is related to #20188 where we are now showing the total number of alerts in the table:
screen shot 2018-07-10 at 9 48 26 am

Testing

To test this PR, please see the individual issues and use a screen reader tool (I used ChromeVox) to ensure the issues are properly addressed

<KuiInfoButton />
<Fragment>
<KuiInfoButton aria-labelledby={`monitoringChart${titleForAriaIds}`} />
<span id={`monitoringChart${titleForAriaIds}`} className="kuiScreenReaderOnly">
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 added this as a way for the screen reader to connect the content in the tooltip with the button showing it. I couldn't do this in the InfoTooltip itself as that doesn't render any DOM until the button is clicked. Perhaps there is a better way?

rowComponent={alertRowFactory(scope, kbnUrl)}
/>
<Fragment>
<p className="kuiText kuiVerticalRhythm" tabIndex="0">Showing {alerts.length} alert(s)</p>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unsure if this is the way we want to show this or if it's in the right place, but I assumed this change would be short lived as we'll be switching this page to EUI soon.

Copy link
Member

Choose a reason for hiding this comment

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

If it's going to be that short lived, then I'd rather we focus on changing it to use EUI instead of this.

Copy link
Member

@tsullivan tsullivan Jul 17, 2018

Choose a reason for hiding this comment

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

Yeah, if EUI will address the issue that introduced this, let's just bring in the fix when the monitoring table component is updated to use EUI.

@chrisronline
Copy link
Contributor Author

Also, should we wait for 6.4 or put this into the next 6.3?

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@pickypg pickypg left a comment

Choose a reason for hiding this comment

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

Mostly about kui* usage.

<KuiInfoButton />
<Fragment>
<KuiInfoButton aria-labelledby={`monitoringChart${titleForAriaIds}`} />
<span id={`monitoringChart${titleForAriaIds}`} className="kuiScreenReaderOnly">
Copy link
Member

Choose a reason for hiding this comment

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

Use <EuiScreenReaderOnly /> instead; try to never use kui*.

@@ -56,6 +56,7 @@ const ToggleCompletedSwitch = ({ toggleHistory, showHistory }) => (
<KuiToolBarSection>
<KuiToolBarText>
<EuiSwitch
aria-label="Completed recoveries"
label="Completed recoveries"
Copy link
Member

Choose a reason for hiding this comment

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

We should probably get EuiSwitch tweaked to have label represent the aria-label. This should be fine in the short term.

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 discussed with @elastic/kibana-design and they mentioned the consumer should manually add aria-label here as the assumption that label and aria-label are the same is not always safe to make.

Copy link
Member

Choose a reason for hiding this comment

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

I do wonder if the default should be for label to be aria-label, but then allow aria-label to be set explicitly for such cases.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm confused as to why you need to add aria-label at all. The rendered HTML of a EuiSwitch should look something like:

<input type="checkbox" class="euiSwitch__input" id="tbav8l2s">
<span class="euiSwitch__body"> 
  ...No need to worry about what's in here...
</span>
<label class="euiSwitch__label" for="tbav8l2s">I am a switch</label>

which connects the input (hidden for the stylized switch look) with the form label via the for and id attributes. By adding another aria-label you will be duplicating that inherit accessibility. So as long as you pass both a label and id, there is no need for aria-label.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah okay. So we either need an explicit aria-label OR add an id. I'd vote the latter. Thoughts?

Copy link
Member

Choose a reason for hiding this comment

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

Sounds reasonable to me. Seems like a good way to get good coverage of its usage.

rowComponent={alertRowFactory(scope, kbnUrl)}
/>
<Fragment>
<p className="kuiText kuiVerticalRhythm" tabIndex="0">Showing {alerts.length} alert(s)</p>
Copy link
Member

Choose a reason for hiding this comment

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

Don't add new usages of kui*. Exclusively use Eui for new content; the only exception is existing usage of KuiTable (which we want to switch over to EuiTable!).

I don't have any strong feelings about this text, but its placement seems abnormal for the rest of Monitoring (and Kibana for that matter). Shouldn't this reported counting issue be solved generically within MonitoringTable?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@tsullivan What are your thoughts here?

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 created #20672 to describe how we might fix this within EUI but I'm still not sure the best place for it here

Copy link
Member

Choose a reason for hiding this comment

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

Just to be clear, MonitoringTable is our wrapper of KuiTable (which hopefully becomes EuiTable soon) and streamlines all of our tables. We could add our own count logic there, but it does make sense to have counts appear near the paging controls, which I assume for accessibility should always be visible even if they're disabled.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@pickypg I moved the results label to the bottom of the table so it looks like:
screen shot 2018-07-11 at 2 11 30 pm

I'm not sure that works great from an accessibility perspective as the user will need to tab through all the rows before seeing the total count, but I'm not an expert here to know for sure.

Any thoughts @elastic/kibana-design?

Copy link
Member

Choose a reason for hiding this comment

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

We could probably accomplish something like @cchaos is showing by adding it to the right of the filter text box? That seems like a good place for the screen reader to get the data as well, especially since we may not know the total versus what we're displaying.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How about:

screen shot 2018-07-11 at 3 00 32 pm

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

👍

Copy link
Member

Choose a reason for hiding this comment

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

@chrisronline I like it, but I cannot remember: is that count the actual total or just the total displayed on that page? If it's the former, then that seems like the other example. If it's the amount displayed on the current page, then the phrasing is misleading.

<h2 className="euiTitle">
{ getTitle(series) }{ units ? ` (${units})` : '' }
<h2 className="euiTitle" tabIndex="0">
<span className="kuiScreenReaderOnly">This chart is not accessible yet</span>
Copy link
Member

Choose a reason for hiding this comment

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

Use <EuiScreenReaderOnly /> instead.

Is this the best way that we can phrase this? It seems kind of stiff to me. Perhaps "This chart does not support screen readers."?

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 took the text directly from the issue which I'm assuming is what we want?

Copy link
Member

Choose a reason for hiding this comment

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

@gchaps Relative to #20191, what do you think about this particular text?

Copy link
Contributor

Choose a reason for hiding this comment

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

How about "This chart is not screen reader accessible" since this text is just for screen reader to announce

@pickypg
Copy link
Member

pickypg commented Jul 10, 2018

Also, should we wait for 6.4 or put this into the next 6.3?

For the things I would deem fixes, 6.3 would be fine, but for the addition I think it should go into 6.4 since it's a visual change.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@tsullivan tsullivan left a comment

Choose a reason for hiding this comment

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

I still need some more time to look at the changes, but first off I I have a suggestion about simplifying a way of creating an array out of different kinds of things

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@tsullivan tsullivan left a comment

Choose a reason for hiding this comment

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

Let's keep all the CSS together, for now :D

@@ -13,6 +13,8 @@ import {
KuiToolBarText
} from '@kbn/ui-framework/components';

import './toolbar.css';

Copy link
Member

Choose a reason for hiding this comment

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

We've been keeping all our CSS separate from public/components, and we have a place in public/less that would be more suitable for the new flex rule in public/less/components/table.less

@@ -54,17 +54,17 @@ const alertRowFactory = (scope, kbnUrl) => {

return (
<KuiTableRow>
<KuiTableRowCell>
<KuiTableRowCell tabIndex="0">
Copy link
Member

Choose a reason for hiding this comment

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

Does each cell really need to be tabbable? Is this just to make it visible to a screen-reader?

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'd imagine so, otherwise the screen reader can't read any of the content in non tabbable cells

Copy link
Member

Choose a reason for hiding this comment

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

I think I've found this to be true myself. I was hoping there'd be another way :D

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@tsullivan
Copy link
Member

The interval in the tooltip is blank:
image

Copy link
Member

@tsullivan tsullivan left a comment

Choose a reason for hiding this comment

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

So close! Just saw a small issue with the interval field not coming through in the chart tooltip.

Also, I was not able to test out the cluster alerts table... having an issue getting cluster alerts to run in the latest ES 7.0 docker snapshot

@chrisronline
Copy link
Contributor Author

@tsullivan Nice catch! Pushed a fix

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@tsullivan
Copy link
Member

this'll need to get updated with master for merge conflicts to resolve

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@chrisronline
Copy link
Contributor Author

@tsullivan All fixed up!

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Member

@tsullivan tsullivan left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@pickypg pickypg left a comment

Choose a reason for hiding this comment

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

LGTM from code

@chrisronline chrisronline merged commit dd40ac3 into elastic:master Aug 8, 2018
@chrisronline chrisronline deleted the monitoring/accessibility branch August 8, 2018 14:39
chrisronline added a commit to chrisronline/kibana that referenced this pull request Aug 8, 2018
* Add screen reader only text for monitoring charts

* Add aria label for completed recoveries

* Ensure we have aria label coverage for monitoring chart tooltips

* Ensure table rows are tabbable and include the number of results at the top

* Use EuiScreenReaderOnly

* Updated copy

* Use EUI

* Remove kui usage

* Use an id instead of aria-label

* Show results in the table footer

* Revert "Show results in the table footer"

This reverts commit d622eb7.

* Show total row count within the monitoring table

* PR feedback

* PR feedback

* Ensure all charts show an interval in the tooltip

* Fix padding issue with the cluster status
chrisronline added a commit that referenced this pull request Aug 8, 2018
* Add screen reader only text for monitoring charts

* Add aria label for completed recoveries

* Ensure we have aria label coverage for monitoring chart tooltips

* Ensure table rows are tabbable and include the number of results at the top

* Use EuiScreenReaderOnly

* Updated copy

* Use EUI

* Remove kui usage

* Use an id instead of aria-label

* Show results in the table footer

* Revert "Show results in the table footer"

This reverts commit d622eb7.

* Show total row count within the monitoring table

* PR feedback

* PR feedback

* Ensure all charts show an interval in the tooltip

* Fix padding issue with the cluster status
@chrisronline
Copy link
Contributor Author

Backport:

6.x: a635df9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants