-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Accessibility] Route changes announcement #150461
[Accessibility] Route changes announcement #150461
Conversation
…-ref HEAD~1..HEAD --fix'
…' into add-screen-reader-only-app-servs
Pinging @elastic/kibana-accessibility (Project:Accessibility) |
onClick(event: React.MouseEvent<HTMLButtonElement, MouseEvent>) { | ||
if (event.button === 0 && !isModifiedOrPrevented(event)) { | ||
event.preventDefault(); | ||
<EuiScreenReaderLive focusRegionOnTextChange> | ||
{i18n.translate('core.ui.recentLinks.linkItem.screenReaderAnnouncement.title', { | ||
defaultMessage: 'type: {title}', | ||
values: { | ||
title: navLink?.title, | ||
}, | ||
})} | ||
</EuiScreenReaderLive>; |
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 don't think this usage of <EuiScreenReaderLive>
within an onClick event is correct - it's not clear that it's actually rendering anywhere meaningful.
Instead of making the screen reader announcement imperative (e.g. firing on click), I think you need to make it reactive (e.g. responding to document.title
changes, which it then stores in state), and only located in 1 place across all apps. Does that make sense? Happy to chat more if not.
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'll plus one to @cee-chen about responding to document.title
and having this centrally located. I've experienced NVDA announce changes inconsistently when the live region is added late. Having it in the DOM on first render()
and then update with document.title
should give a consistent experience.
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.
Ok thank you both! I think I'm following - updated in 226e5e0
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.
Feb-14-2023.10-25-32.mp4
- let's see if this fixes FTR shenanignas
@@ -38,5 +38,5 @@ export const ScreenReaderRouteAnnouncements: FC<{ | |||
} | |||
}, [breadcrumbs]); | |||
|
|||
return <EuiScreenReaderLive focusRegionOnTextChange>{routeTitle}</EuiScreenReaderLive>; | |||
return <EuiScreenReaderLive aria-live="assertive">{routeTitle}</EuiScreenReaderLive>; |
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.
@1Copenut I set aria-live
to assertive
to make up for the removed focus behavior - not sure if this was the right move or is overly aggressive. Do you mind testing? 🙇
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.
from my testing: it works maybe 75% of the time on Safari+VO but not 100% of the time (for whatever reason, no idea why). Would feel better if we had JAWS and NVDA data.
lmfao ok i figured out the other FTR failures. I am incredibly curious about whether it's just Canvas that throws after I fix that issue though, so I'm going to re-re-revert |
Failures now appear to be limited to Canvas and Discover (since discover has custom h1 focusing logic). Super dumb one-off workarounds here we go! |
I did further testing on the morning of 24 February with Safari + VoiceOver. The latest changes are solid and behavior matches what I've experienced in other live-region testing. Safari + VO has a tendency to not announce a live region the first time it loads a view with a lot of async data and/or JS rendering, but I've witnessed that before. It also tends to smooth out when the view is loaded subsequently. I expect we'll get more consistent results with NVDA and JAWS. I'll do more testing with those screen readers as time permits. Cee mentioned that Canvas is dynamically rebuilding the breadcrumbs as users rename the workpad. There's code in the PR to ignore this, but I was still able to trigger the live region as I edited a workpad. Let me know if I should pull code again and retest this behavior. I don't consider this worth holding up the PR--it's actually an opportunity to improve the Canvas renaming behavior with a "Save" or "Go" button. I'll add a ticket for the Discover app to remove our earlier H1 focus workaround and point to this PR. Much appreciated! |
💚 Build Succeeded
Metrics [docs]Module Count
Page load bundle
History
To update your PR or re-run it, just comment with: cc @rshen91 |
Summary
Closes #149212 and closes #149213
This PR was tested with VoiceOver on Safari, Firefox and Chrome.
Checklist