-
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: Fix NVDA menu item counts that are broken by <form>
#2822
Conversation
🦋 Changeset detectedLatest commit: 418b6cc 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 |
LGTM! Including @jonrohan too for another set of 👀 |
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.
This looks good to me (after reading through the Slack thread) although it does feel weird. Seems like the best solution we can implement right now that will fix this accessibility violation 🤷
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.
Looks good 👍🏻 I'll leave this to @camertron to merge into the current release, or wait until next one. We're close to shipping the current release and don't want to add more on the plate at the moment.
The |
Related PR: #2828 |
What are you trying to accomplish?
Fixes https://github.com/github/accessibility-audits/issues/7582 (Hubber login required)
When a
role="menu"
element contains a<form>
, NVDA skips over that<form>
’srole="menuitem"
children.NVDA generally announces “menu item i of t” for every menu item. However, NVDA neither announces an “i” (item index), nor sums in “t” (total item count), any
role="menuitem"
element inside a<form>
.Here are two examples:
NVDA announces that this menu has 3 items, but it has 4. If, using browser devtools, you add
role="none"
to the<form>
, then NVDA correctly detects the 4 menu items.This occurs on https://github.com/orgs/github/projects (Hubber login required). Under “Recently viewed” projects, in the three-dot “More project options” menu (to the right of each project), NVDA doesn’t count “Close project” and “Remove from recently viewed” as menu items. Both are forms-inside-menu.
List the issues that this change affects.
Closes https://github.com/github/accessibility-audits/issues/7582 (Hubber login required)
Risk Assessment
I’m rating this as medium risk, because I don’t know how likely we are to detect unintended side-effects of this change. I don’t know the relevant components’ test coverage.
What approach did you choose and why?
I chose to suppress the
<form>
element’s implicitrole="form"
usingrole="none"
. This makes its childrole="menuitem"
element become a direct child of therole="menu"
element in the accessibility tree. This makes NVDA announce the child menu item properly.I asked if this would break anything, in #accessibility (Hubber login required).
@zersiax
said: “…nulling the form semantics is what people generally do in this case…carry on.”Notably, as of 418b6cc,
role="none"
is only applied for<form>
s insideActionMenu
s, not<form>
s insideActionList
s generally.Anything you want to highlight for special attention from reviewers?
Do we have adequate test coverage to feel safe from unintended side-effects?
Do I need to update any docs?
Accessibility
Merge checklist
Take a look at the What we look for in reviews section of the contributing guidelines for more information on how we review PRs.