Skip to content

Danielle/610-a11y-menu-controls-not-screenreader-accessible #661

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.

Sign up for GitHub

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

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

Danielle/610-a11y-menu-controls-not-screenreader-accessible #661

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
f1481d0
fix: make close button for navigation menu accessible to screen readers
Danielle254 Jan 8, 2025
60ad3cb
fix: a11y - add properties to make hamburger menu icon screenreader a…
Danielle254 Jan 8, 2025
f7e58e1
fix: address eslint issues with code formatting
Danielle254 Jan 8, 2025
b293510
fix: keep original aria-haspopup='dialog' setting by removing overrid…
Danielle254 Jan 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 9 additions & 2 deletions components/Nav/Nav.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,8 +61,15 @@ export const Nav = (): JSX.Element => {
<ul>
<li>
<Drawer open={open} onOpenChange={setOpen}>
<DrawerTrigger data-testid="drawer-trigger">
<Menu className="text-foreground" />
<DrawerTrigger
data-testid="drawer-trigger"
aria-haspopup='menu'

@CorinaMurg CorinaMurg Jan 13, 2025

Copy link
Copy Markdown
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.

@Danielle254 Danielle254 Jan 14, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

resolved

aria-label='open navigation menu'

@CorinaMurg CorinaMurg Jan 13, 2025

Copy link
Copy Markdown
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.

@Danielle254 Danielle254 Jan 14, 2025

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

@CorinaMurg CorinaMurg Jan 13, 2025

Copy link
Copy Markdown
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?

@Danielle254 Danielle254 Jan 14, 2025

Copy link
Copy Markdown
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

@Danielle254 Danielle254 Jan 14, 2025

Copy link
Copy Markdown
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.

/>
</DrawerTrigger>
<DrawerContent>
<DrawerHeader>
Expand Down
6 changes: 4 additions & 2 deletions components/NavDrawer/NavDrawer.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -128,8 +128,10 @@ const DrawerTitle = React.forwardRef<
{...props}
/>

<DrawerClose>
<X />
<DrawerClose aria-label='close navigation menu'>
<X
aria-hidden='true'
/>
</DrawerClose>
</div>
));
Expand Down