-
Notifications
You must be signed in to change notification settings - Fork 12
Add modal launcher details to docs #2875
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
Conversation
🦋 Changeset detectedLatest commit: 9d29c92 The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
GeraldRequired Reviewers
Don't want to be involved in this pull request? Comment |
|
Size Change: 0 B Total Size: 109 kB ℹ️ View Unchanged
|
A new build was pushed to Chromatic! 🚀https://5e1bf4b385e3fb0020b7073c-kditebicgj.chromatic.com/ Chromatic results:
|
beaesguerra
left a comment
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.
Thanks for adding these docs!
14cb685 to
684802c
Compare
|
Added fixes for the Modal a11y issues in stories! https://khanacademy.atlassian.net/browse/WB-2161 |
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.
Thanks for taking a look at the modal a11y issues! I left some questions around whether the original examples were valid use cases. I wanted to check first since this may signal underlying a11y issues for existing usage that follow the same patterns in the original examples. Let me know what you think!
(Also, I see there are similar a11y issues in other modal stories. If it's something we can fix at the component level, then we can address the others too! Sorry I didn't list out all the modal stories with issues in the ticket!)
| <View style={styles.modalPositioner}> | ||
| <FlexibleDialog | ||
| aria-labelledby="main-heading" | ||
| title={ |
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 this mean the heading should always be in the title prop? Are there use cases that consumers would need where it is part of the content?
I was assuming manually configuring aria-labelledby meant a custom implementation of the title was needed, since using the title prop will auto-wire up the attributes already!
wonder-blocks/packages/wonder-blocks-modal/src/components/flexible-dialog.tsx
Lines 143 to 152 in 7065e96
| const renderedTitle = | |
| title == null ? null : typeof title === "string" ? ( | |
| <Heading id={headingId}>{title}</Heading> | |
| ) : ( | |
| // Augment heading element with ID/testId | |
| React.cloneElement(title, { | |
| id: headingId, | |
| testId: "title-heading-wrapper", | |
| }) | |
| ); |
I also noticed that the aria-labelledby prop provided by the consumer doesn't end up getting used (other aria attributes are applied though!). This might be what was causing an issue with the original example?
wonder-blocks/packages/wonder-blocks-modal/src/components/flexible-dialog.tsx
Lines 159 to 161 in 7065e96
| aria-label={accessibilityProps["aria-label"]} | |
| aria-labelledby={headingId} | |
| aria-describedby={accessibilityProps["aria-describedby"]} |
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.
The component is intended to use the title prop so naming can be handled automatically, with the option for it to be inserted into content with the title render prop. But the story originally included an aria-labelledby example that didn't work properly, and it was a little confusing outside of the happy path. I opened a separate ticket to revisit naming with aria-labelledby, since it's a little more involved than fixing up some stories: https://khanacademy.atlassian.net/browse/WB-2168
| content={ | ||
| <> | ||
| {longBody} | ||
| {button} |
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 there is scrollable content in a modal and no interactive elements within it (like the original example without the button), should we add tabIndex=0 to the scrollable container, similar to what's done in frontend with ScrollableView?
I'm wondering if there are valid use cases where there might not be an interactive element within the scrollable modal content that would prevent scrolling via keyboard! What do you think?
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 made some updates to ensure scrollability with the keyboard on those internal View components, and added the global focus style.
I will add that I don't love wrapping an internal View with tabIndex=0 though, because it needs an interactive role and accessible name for screen reader users as well. But these are already provided at the dialog level, and using the same ID reference for this scrollable container is doubly confusing...so I'm at a loss for how to name it. Maybe "scroll container" or something? That seems more like an aria-roledescription than a name, since it wouldn't really be unique.
What I'd love to see is some dynamic keyboard scroll handling so consumers don't have to manually add tabIndex attributes, accessible names, and widget roles. Ideally the browser would deal with it. But maybe ModalPanel (and ScrollableView in frontend, for that matter) could detect overflow scrolling as well as interactive components to deal with it conditionally.
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.
Here's an issue for it: https://khanacademy.atlassian.net/browse/FEI-7356
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.
Thank you for creating a ticket! I agree that this would probably need a broader solution! The keyboard scrolling issue is also related to the SimpleTable a11y fixes I'm working on in https://github.com/Khan/frontend/pull/5786
Ideally the browser would deal with it. But maybe ModalPanel (and ScrollableView in frontend, for that matter) could detect overflow scrolling as well as interactive components to deal with it conditionally.
FWIW, Chrome + Firefox on macOS will automatically make a scrollable div focusable! Safari does not 😢 https://jsfiddle.net/qorx1a5b/3/
npm Snapshot: NOT Published🤕 Oh noes!! We couldn't find any changesets in this PR (8a2046f). As a result, we did not publish an npm snapshot for you. |
beaesguerra
left a comment
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.
Approving again for the modal a11y story fixes! Thanks for creating follow up tickets :)
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2875 +/- ##
============================
============================
Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
Summary:
After making bugfixes and updates to conditionally rendered modals, I figured we should update the docs.
Note: the ModalLauncher and DrawerLauncher descriptions are only rendered from stories files
Issue: WB-2103
Test plan: