-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Monitoring] Address multiple accessibility issues #20619
Conversation
<KuiInfoButton /> | ||
<Fragment> | ||
<KuiInfoButton aria-labelledby={`monitoringChart${titleForAriaIds}`} /> | ||
<span id={`monitoringChart${titleForAriaIds}`} className="kuiScreenReaderOnly"> |
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 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> |
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.
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.
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.
If it's going to be that short lived, then I'd rather we focus on changing it to use EUI instead of this.
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, 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.
Also, should we wait for 6.4 or put this into the next 6.3? |
💚 Build Succeeded |
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.
Mostly about kui*
usage.
<KuiInfoButton /> | ||
<Fragment> | ||
<KuiInfoButton aria-labelledby={`monitoringChart${titleForAriaIds}`} /> | ||
<span id={`monitoringChart${titleForAriaIds}`} className="kuiScreenReaderOnly"> |
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.
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" |
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.
We should probably get EuiSwitch
tweaked to have label represent the aria-label
. This should be fine in the short term.
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 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.
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 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.
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'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
.
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.
Ah okay. So we either need an explicit aria-label
OR add an id
. I'd vote the latter. Thoughts?
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.
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> |
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.
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
?
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.
@tsullivan What are your thoughts here?
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 created #20672 to describe how we might fix this within EUI but I'm still not sure the best place for it here
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.
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.
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.
@pickypg I moved the results label to the bottom of the table so it looks like:
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?
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.
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.
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.
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.
@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> |
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.
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."?
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 took the text directly from the issue which I'm assuming is what we want?
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.
How about "This chart is not screen reader accessible" since this text is just for screen reader to announce
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. |
💔 Build Failed |
💚 Build Succeeded |
💔 Build Failed |
💚 Build Succeeded |
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 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
💚 Build Succeeded |
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.
Let's keep all the CSS together, for now :D
@@ -13,6 +13,8 @@ import { | |||
KuiToolBarText | |||
} from '@kbn/ui-framework/components'; | |||
|
|||
import './toolbar.css'; | |||
|
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.
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"> |
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.
Does each cell really need to be tabbable? Is this just to make it visible to a screen-reader?
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'd imagine so, otherwise the screen reader can't read any of the content in non tabbable cells
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 I've found this to be true myself. I was hoping there'd be another way :D
💚 Build Succeeded |
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.
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
@tsullivan Nice catch! Pushed a fix |
💚 Build Succeeded |
this'll need to get updated with master for merge conflicts to resolve |
💚 Build Succeeded |
@tsullivan All fixed up! |
💚 Build Succeeded |
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
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 from code
* 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
* 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
Backport: 6.x: a635df9 |
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:
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