-
Notifications
You must be signed in to change notification settings - Fork 843
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) NVDA/JAWS support for EuiGlobalToastList
#2055
Conversation
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 am not well versed in aria-live
regions, but it looks like you tested in a lot of browsers and assistant tech so I'll trust your implementation.
Double checked with @maryia-lapata that VoiceOver works as before this PR. |
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, tested on VoiceOver, Mac, it works as expected.
I got a quick question. Is the title of the toast getting announced for you @maryia-lapata in voice-over? All I get is the content of the toast. In this case here: the voice over announces thanks for your patience and doesn't announce Download complete |
@bhavyarm I've just checked, the title of the toast is getting announced: |
@maryia-lapata great. I thought it was some combination of voice-over, os x combination. Thank you! |
Closes #1947
Summary
Every toast has an aria-live attribute, there is no live region at all.
It does work: VoiceOver
It doesn't work: NVDA, JAWS.
✅ Now
A live region role="region" initializes at the component mounting,
the globalToastList is an aria-live region itself now.
Thus the Screen Reader understands where it should wait for updates.
Have a look at #1947 issue's description, there are a couple of links to standard explanations.
It does work: VoiceOver, NVDA, JAWS
It doesn't work: n/a
Expected behaviour
Once a toast notification is rendered, it is getting be announced.
At the moment of the next toast coming, Screen Reader may stop saying and start announcing the coming one.
Some screen readers may finish first announcing the previous notification and after that start another one.
Checking against ScreenReaders
✅ VoiceOver + Safari
✅ NVDA + Firefox
✅ NVDA + IE11
✅ Narrator + Edge
✅ NVDA + Chrome
Checklist
This was checked in mobileAny props added have proper autodocsDocumentation examples were addedThis was checked for breaking changes and labeled appropriatelyThis required updates to Framer X components