-
Notifications
You must be signed in to change notification settings - Fork 1
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
Danielle/610-a11y-menu-controls-not-screenreader-accessible #661
base: develop
Are you sure you want to change the base?
Danielle/610-a11y-menu-controls-not-screenreader-accessible #661
Conversation
Gridiron Survivor Application
Project name: Gridiron Survivor Application
Only deployments on the production branch are activated automatically. If you'd like to activate this deployment, navigate to your deployments. Learn more about Appwrite Function deployments.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
components/Nav/Nav.tsx
Outdated
<Menu className="text-foreground" /> | ||
<DrawerTrigger | ||
data-testid="drawer-trigger" | ||
aria-haspopup='menu' |
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.
What we have it's just a navigation component, so it cannot take the role of menu
. If we were building a desktop application like Google Docs, then the “File”, “Edit” etc would each be assigned role=menu
. Power screen reader users expect certain keyboard functionality when they hear “menu” (e.g. tab to certain elements, then navigate with arrow keys, make use of Home
, Space
keys, etc) and a site navigation really does not need this functionality.
We (and everybody on the planet) use the term “menu” but technically a hamburger navigation is just a disclosure widget. A button with aria-expanded
that toggles the visibility of the nav drawer would be enough. Very unlikely we’ll find a ready-built component like that. Most are built like dialogs.
A dialog
is a bit of an overkill for a navigation component, but it’s not wrong. Dialog means that the drawer is overlaid on top of the rest of the content, and that the rest of the content is inert while the drawer is visible. The keyboard focus is kept inside the drawer, and the screen reader users know they first have to close it before accessing content outside the drawer. And our drawer does just that.
My suggestion is to keep it as is for right now. Unless we want to implement a disclosure widget. But this is also a component that’s evolving in terms of its content. It will probably have user account info, maybe a search input. It’s not a bad idea to have it as a dialog.
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.
resolved
components/Nav/Nav.tsx
Outdated
<DrawerTrigger | ||
data-testid="drawer-trigger" | ||
aria-haspopup='menu' | ||
aria-label='open navigation menu' |
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.
"Menu" should be enough for the name. That's the name that voice users expect from the hamburger icon. Screen reader users will learn it's a button that opens a dialog.
aria-label
is not the best way to name an interactive component. For one, it's not guaranteed that browsers will translate the string. Once we are close to wrapping up the project, we'll see how many elements with no visible label we have, and we should use a different approach. But for right now, let's just keep aria-label.
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.
resolved
> | ||
<Menu | ||
className="text-foreground" | ||
aria-hidden='true' |
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.
Why aria-hidden
? It removes the component from the accessibility tree. Or is <Menu>
strictly just the svg
?
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.
<Menu>
is strictly the SVG icon from the lucide-react library
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 drawer trigger button is a parent and is labeled.
…e property, make aria-label for menu less verbose
Current State:
the controls to open and close the navigation menu are represented by icons only, no description. There are also no aria labels to tell screen reader users what these buttons/icons do. This is a big a11y issue.
There was an additional issue discovered, which is that the Shadcn component
Drawer
has a propertyaria-haspopup='dialog'
by default, which is incorrect for this usage (should bearia-haspopup='menu'
).Fix:
Overrode default
aria-haspop
property with correct value (='menu'
) for the hamburger menu button.Gave SVG icons the property
aria-hidden='true'
to tell screen readers to ignore them.Gave the open and close buttons
aria-label
properties to tell screen readers what these buttons are for - accessing the navigation menu.