-
Notifications
You must be signed in to change notification settings - Fork 116
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
Fix accessibility bug of missing accessible name on Dialog #2210
Conversation
🦋 Changeset detectedLatest commit: 4a59f8d The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
6b1a1b9
to
ec170fb
Compare
63e711a
to
867fe44
Compare
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.
Nice! Thanks for this fix! ✨
I am not authorized so please merge in, thank you! |
What are you trying to accomplish?
When I was doing unrelated work in dotcom, I noticed that
Primer::Alpha::Dialog
is not rendering with an accessible name resulting in an Axe failure of aria-dialog-name:This is unexpected since having an accessible name is also clearly documented in the docs.
There's currently no corresponding behavioral test written for this component. It's likely we're not running an axe scan when the Dialog is an open state, causing us to miss this error.
This PR fixes the bug and adds a behavioral system test.
List the issues that this change affects.
Closes https://github.com/github/primer/issues/2556
Risk Assessment
What approach did you choose and why?
Fix bug and add missing behavioral test.
Accessibility
Merge checklist
Questions to reviewers
📣 Are behavioral components (or components that render with JS) identified in any way? I couldn't find anything that would indicate a component has JS associated with it. I was thinking it might be worth having a check that ensures all behavioral components have a corresponding
system_test
written.This is beneficial because it would ensure that we have checks in place for how a component should behave, and would also make sure that axe is ran against various states of the component (e.g. when dialog is open). This is also extra important because we don't seem to have custom element tests. This would help surface more accessibility or behavioral issues at the testing stage.