-
Notifications
You must be signed in to change notification settings - Fork 427
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
Modal: Focus close button on open. Fallback to wrapping container div if no close button #2018
Comments
Is this a side-effect of the initially focused element on Modal loading is the invisible container element that then reads all of the Modal contents? |
It may be. I suspect the screen reader identifies the focus and then reads all of the content as interactive. What do you think? |
All the content is grouped in a |
Yep--that's the problem I think. How can we move the content out from this div? Or can we? |
We could remove the |
Yes, our modals do have close buttons. I don't know of any that don't. So, could we move focus to the close button instead of the entire div contents? |
Yes. I agree. |
https://design-system-react-co-pr-2004.herokuapp.com/?selectedKind=SLDSModal&selectedStory=Modal%20with%20Custom%20Parent%20Node&full=0&addons=1&stories=1&panelRight=0&addonPanel=storybook%2Factions%2Factions-panel
Issue: Screen readers read all lines of text as "clickable", sometimes reading multiple "clickable" before reading the content
Potential cause: Most likely a click handler is higher in the DOM (maybe the close button?) and everything inside this becomes clickable as well.
Possible solutions: Is it possible to wrap the click event in a clickable event that is not the parent for the other child elements that are reading as clickable? Please see this (older) WebAIM thread that has a long discussion of this type of issue for other potential solutions (https://webaim.org/discussion/mail_thread?thread=7693)
The text was updated successfully, but these errors were encountered: