Bug(navbar): languages and doc version drop downs are inaccessible via the keyboard and screen reader

[dawei-wang]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Prerequisites

• I'm using the latest version of Docusaurus.
• I have tried the npm run clear or yarn clear command.
• I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
• I have tried creating a repro with https://new.docusaurus.io.
• I have read the console error message carefully (if applicable).

Description

The languages and docs version drop-down menus are not accessible via the keyboard. This violates WCAG 2.1.1 which states that all functionalities on the website must be accessible via the keyboard. Drop-down menus don't fall under the exceptions of freehand drawing, or a game intended to teach a specific movement.
https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html
https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Operable

Reproducible demo

No response

Steps to reproduce

1. Start NVDA
2. Navigate to https://docusaurus.io/
3. Tab to the 2.2.0 menu
4. The user is unable to activate the menu with the keyboard
5. Tab to English menu
6. The user is unable to activate the menu with the keyboard

Inaccessible.drop-down.menu.demo.mp4

Expected behavior

I thought the menus would open automatically as I tabbed to them giving me the option to choose the doc version and language with the arrow keys and enter key. I also expect to be able to close the menu by pressing tab again.

Actual behavior

I am unable to activate the menus at all with the keyboard.

Your environment

• Public source code:
• Public site URL: https://docusaurus.io/
• Docusaurus version used: 2.2.0
• Environment name and version (e.g. Chrome 89, Node.js 16.4): Edge 108
• Operating system and version (e.g. Ubuntu 20.04.2 LTS): Windows 11

Self-service

• I'd be willing to fix this bug myself.

[Josh-Cena]

It may be a little unexpected, but dropdowns are expanded with Enter, not Tab. This is because dropdowns can get long, and we don't want tab navigation to get stuck in a dropdown.

[dawei-wang]

@Josh-Cena That makes sense, but the menus do not expand with enter either. When I am on the doc version selection drop down and press enter, it takes me to the introduction page.

[slorber]

@Josh-Cena That makes sense, but the menus do not expand with enter either. When I am on the doc version selection drop down and press enter, it takes me to the introduction page.

It is not the case for me, the dropdown should expand (with enter), can you double-check?

CleanShot.2022-12-23.at.11.55.39.mp4

Which browser/OS to reproduce?

[dawei-wang]

The drop down works without the screen reader enabled but does not work if NVDA screen reader is enabled. I am on Windows 11, Edge 108

[dawei-wang]

I run into the same issue if I try to access the menus with the Windows narrator turned on.

[slorber]

Do NVDA or Windows narrator prevent pressing enter somehow?

Are other users of these tools experiencing the same problem?

cc @timveld @BenDMyers maybe you can help us figure this out?

[Josh-Cena]

The issue is not actionable until someone else with the same setup can confirm. Awaiting more information on this.

[srapilly]

@Josh-Cena I can reproduce with NVDA, it's because NVDA will trigger the onClick when using enter/space to trigger the button. nvaccess/nvda#7898 (comment) (you can reproduce with Voiceover also if yo use Control + Option + Space)

So in the DropdownNavbarItem component, it will trigger the onClick:

docusaurus/packages/docusaurus-theme-classic/src/theme/NavbarItem/DropdownNavbarItem.tsx

Lines 87 to 102 in 1293970

	<NavbarNavLink
	aria-haspopup="true"
	aria-expanded={showDropdown}
	role="button"
	href={props.to ? undefined : '#'}
	className={clsx('navbar__link', className)}
	{...props}
	onClick={props.to ? undefined : (e) => e.preventDefault()}
	onKeyDown={(e) => {
	if (e.key === 'Enter') {
	e.preventDefault();
	setShowDropdown(!showDropdown);
	}
	}}>
	{props.children ?? props.label}
	</NavbarNavLink>

The things to improve in the component in my opinion, I can make a PR:

Button instead of link and remove the role attribute

ARIA roles just change the way elements are exposed to assistive technologies, it will not add any behavior, for example, you can trigger a button with the SPACE key, this is not the case with the current navbar button. Great article about this: https://www.erikkroes.nl/blog/aria-roles-do-very-little/

Windows High Contrast Mode also doesn't care about ARIA roles, so the navbar buttons will appear as links for users of this assistive technology.

I guess it was done with an anchor to make it work without JS, but it's not working with a keyboard interface if you remove JS. I think we don't really have a choice to use a button here to make it better. The new Popover attribute will be nice, but not yet well supported

Remove aria-haspopup

aria-haspopup=true is equivalent to aria-haspopup=menu When using this attribute, the container of the popup should match the role menu. The popup currently does not have this role.

A menu is not ideal in this case, it should be used for menu that are similar to desktop application and it adds complexity. Great article about this: https://adrianroselli.com/2017/10/dont-use-aria-menu-roles-for-site-nav.html

https://w3c.github.io/aria/#menu

A menu is often a list of common actions or functions that the user can invoke. The menu role is appropriate when a list of menu items is presented in a manner similar to a menu on a desktop application.

[natedx]

Hello, I ran into this problem while checking accessibility for our docusaurus website. Would it be possible to review @srapilly 's PR and get this merged?
For context, our website is meant to be used by blind users using Voiceover. Accessibility is very good everywhere else in docusaurus plugins but currently our users are unable to switch languages.
In terms of accessibility, preventing defaults for onClick and onKeyPress will almost always mess up screen readers...

[slorber]

@natedx I will try to take a look soon but I don't have great accessibility skills and it's always hard to spend hours trying to figure out if things are accessible, and annoying to merge PRs blindly trusting the author things are an improvement.

I also don't have all the OS and software on my computer to test changes are safe for all assistive setups 😅 And I barely know how to use assistive software either.

Can you help review the PR?

Usually, if I see a few blind/disabled people mentioning that the new behavior is an improvement, I'm more likely to review/merge the PR faster.