Skip to content
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

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from

Conversation

Danielle254
Copy link
Contributor

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 property aria-haspopup='dialog' by default, which is incorrect for this usage (should be aria-haspopup='menu').

GIS hamburger menu before
GIS close menu before

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.

GIS hamburger menu after
GIS close menu after

Copy link

appwrite bot commented Jan 8, 2025

Gridiron Survivor Application 6616ea581ef9f5521c7d

Function ID Status Action
Your function has been successfully deployed.

Project name: Gridiron Survivor Application
Project ID: 6616ea581ef9f5521c7d

Function ID Status Action
userAuth 6626fef885a9f630442b ready Ready View Logs

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.

💡 Did you know?
Appwrite has a Discord community with over 16 000 members. Come join us!

Copy link

vercel bot commented Jan 8, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
gridiron-survivor ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 14, 2025 7:20pm
gridiron-survivor-storybook ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 14, 2025 7:20pm

@Danielle254 Danielle254 requested a review from CorinaMurg January 8, 2025 17:51
@Danielle254 Danielle254 added the a11y accessibility related label Jan 8, 2025
<Menu className="text-foreground" />
<DrawerTrigger
data-testid="drawer-trigger"
aria-haspopup='menu'
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved

<DrawerTrigger
data-testid="drawer-trigger"
aria-haspopup='menu'
aria-label='open navigation menu'
Copy link
Contributor

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.

Copy link
Contributor Author

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'
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y accessibility related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants