WIP: Nav Menu: dropdown menu won't open with NVDA screen reader active

Bugs
1

Browser: FireFox Developer
OS: Windows 11
URL: https://starter-bricks.9planetshosting.com/
Video: Bricks Menu won't open with NVDA Screen Reader active | Loom

Tab navigation works when the screen reader is off. When you turn it on, it doesn’t work for the dropdown menu.

I tried it on a buildbuilder test site: Log In ‹ Try Bricks – tea249d3 — WordPress it doesn’t work either.

Interestingly, the menu at bricksbuilder.io does work.
Is the menu you’re using on the main site different?

Is there a way to basic menu to work?

I’m not sure if this is relevant but I did a little searching and found this:
https://stackoverflow.com/questions/69126894/keyboard-tabbing-doesnt-work-when-screen-reader-in-enabled

Where they say: screen readers suppress some native javascript events. stackoverflow.com/questions/65181014/… In my case onKeyPress doesn’t get fired at all when screen readers are enabled.

1 Like
2

@nineplanets, the Bricks website is using the Nav (Nestable). For the Nav (Nestable), you need to set the dropdown to open on Hover or Click, otherwise it would not work with NVDA.
Unfortunately, there’s no option for that with the standard menu. I’m also not a fan of the output which uses separate <nav> for desktop and mobile.

image
image750Ă—740 34.8 KB

3

We’re switching to the Nav (Nestable) element, but running into another accessibility issue. When you’re using keyboard navigation and open the mobile menu, it doesn’t seem to include a focus trap or auto-close when out of focus, so after you tab through the menu options, you just keep tabbing to other elements on the page that are covered up by the mobile menu that stays open. Do you happen to know a way to either focus trap the tabbing until they close the menu, or just auto-close it when you lose focus on the menu?

4

I’m just about to start researching how to improve the accessibility of the Nestable Nav. Currently, the mobile trigger button is added as the last focusable element instead of the first. It also adds the close button as an <li>, among other issues.

What I believe is that you’d need to create a separate <div role="dialog" aria-label="..."> which would contain the close button and a separate <ul> for the mobile menu. That’s the best way to trap focus.

If I’m not mistaken, the Bricks team is currently in talks with Amber Hinds about improving the overall accessibility of their elements.

5

Hi @nineplanets,
Thanks so much for your report(s)!

One of my colleagues can reproduce issue #1 regarding NVDA and the regular nav menu dropdowns on Windows (unfortunately, NVDA is only available on Windows - it works with Apple Voiceover, though), so we’ve added it to the bug tracker.

We also created an improvement task regarding issue #2, the nav-nestable mobile menu and keyboard navigation.

Best regards,
timmse

1 Like
6

VoiceOver controls are different, it doesn’t automatically enter browse mode.
To experience the problem on VoiceOver, activate the Lock VoiceOver keys using (Ctrl + Option + semicolon). That’ll give you a similar experience to the NVDA browse mode.

1 Like
7

I tried setting up the role=“dialog” stuff, but it didn’t seem to focus trap things.

8

@nineplanets

I kept running into some issues with Bricks code so I ended up just recreating one from scratch to test as shown on my demo site.

The structure I’m expecting is as shown in the image below. Although it is far from perfect, I believe the focus should be trapped.

image
image675Ă—570 26.4 KB

9

Hi @nineplanets,

After reviewing the issue, it seems this isn’t a bug with Bricks but rather how Windows Narrator and NVDA handle key inputs. By default, Windows Narrator assigns the “Narrator key” to “Caps Lock or Insert” which can interfere with the “Enter” key. It also replaces the normal “Enter” key functionality with “Control + Space”.

To resolve this, you can either use “Control + Space” to toggle the submenu or adjust the Narrator settings to set the “Narrator key” to “Caps Lock” only. This should restore the expected functionality of the “Enter” key.

windows-narrator
windows-narrator2334Ă—1756 232 KB

10

We shouldn’t have to change NVDA settings to adapt to a webpage; it should be the reverse. (See WCAG Principle about being Robust)

The way screen readers (NVDA) work is that when they detect a pattern—using the correct semantics and ARIA information—they automatically disable whichever event listeners they need to disable to restore normal keyboard functionality.

So I suspect, it is expecting a click event. I’m no expert, I’m just speculating.

Remember that NVDA is not just a testing tool. It is what people use in their everyday life. So saying we should adjust the screen reader settings is not a viable solution.
I suppose the “solution” might be to set the default to open the dropdown on “hover or click”.

Then maybe you could add a warning or note when a user chooses the option to open on only hover, that it may have problems with assistive technology. That’s what some plugin devs do.

2 Likes
11

I agree with Daveden2. We can’t put a notice on our website that if you use NVDA you’ll need to change your settings. That would not pass accessibility.

12

One of our websites was audited for accessibility and this was listed as an issue. According to WCAG, users should not be required to make changes to screen reader default settings if a site does not function as expected.

I will do some more tests and see if adding “role=“dialog”” to the dropdown indicator fixes this.

I do hope the team at Bricks will look into this matter.

13

Just to provide an update on: I agree, users shouldn’t have to change screen reader settings. We added this back to the bug tracker after confirming the issue, but we haven’t pinpointed the root cause yet.

14

@Daveden2 thank you for the structure provided, and all your videos regarding to accessibility on Youtube. Would you also not recommend using a separate nav for mobile if its in an offcanvas element?
I created a menu with this tutorial: https://youtu.be/SZcPeCzWV2s?si=Jt9q29ocEBMXq7Gm
But it uses a separate navigation for mobile.
I am not sure how can I make this with one navigation element.

15

Code-wise, it is recommended to have a single navigation that turns into mobile navigation, but there are no accessibility requirements for this approach.

As we know, if you want to use a burger trigger element and off-screen menu element, it’s much easier and faster to implement this by using multiple navigation elements. This is what we have been doing, and we haven’t seen any real-life cons with it.

2 Likes
16

Thank you @Arvoisa for your answer!
I want to make sure I am keeping up with best practices and also respect accessibility.

17

Yes, it is recommended to have one <nav> element to wrap all your navigation elements, preferably with a name (`<nav aria-label=“Primary”). This tells the browser and assistive technologies that everything inside the section is for primary website navigation.

From the video, I can see that the trigger button for the off-canvas menu is still within the <nav>. This is good for screen reader users because when they use their keyboard to land on the primary navigation, it will then announce the mobile menu [trigger button].

But if the trigger <button> is outside the <nav>, assistive tech will announce that there’s no navigation on the page if they’re viewing the mobile menu breakpoint. The reason is because the content in the <nav> would be hidden and the <button> is outside the <nav>.

Basically, assistive technologies have keyboard shortcuts or context menus that allow quick jumping between landmarks—header, nav, main, footer, and aside.

18

@charaf Our team was able to fix it with additional JavaScript. I tested it in NVDA and it’s now working properly. It may not be as good as an official fix, but it may point you toward what needs to be done:

	document.querySelectorAll('.brx-submenu-toggle button').forEach( el => {
		el.addEventListener( 'click', e => {
			e.preventDefault();
			e.target.closest('li').classList.toggle('open');
			e.target.closest('button').setAttribute( 'aria-expanded', e.target.closest('button').getAttribute('aria-expanded') == 'true' ? 'false' : 'true' );
			// el.dispatchEvent( new KeyboardEvent( 'keydown', { key: 'Enter', code: 'Enter', keyCode: 13, which: 13, bubbles: true }) );
		}, true );
	});
1 Like