WordPress Menu Accessibility – 10 Menus Compared: Practical Tests

Today, I have part one of a two-part series where I test the accessibility of 10 different menus from some of the most popular WordPress themes and Page Builders.

In this video, I’ll show you how we do some practical accessibility testing on menus, and I’ll point out some of the most common issues we find. In the next video, we’ll dive deep into the criteria I tested each menu against, and we’ll see how they all stack up.

I’m Adam Lowe, President of Peak Performance Digital. If you find content like this helpful, I’d love it if you can give me a thumbs up and hit that subscribe button. It may not seem like much, but it means a lot to me.

And hey, leave a comment down below, too, while you are at it. It’s great hearing from you and answering your questions.

Alright, back to our topic for today…

Whenever I review a website for accessibility issues, I pay special attention to how the menus work. Not only are they a relatively complicated website component, but they can make or break a visitor’s experience. I can’t tell you how many websites I’ve come across where the menu is simply not usable for someone who relies on a screen reader or who can’t navigate with a mouse.

This video actually came about because I wanted to check and adjust the menu component I use as a template for my client projects. Of course, the minute I started diving into it, things got complicated fast.

As with most things accessibility-related, there are no hard and fast rules. That would be way too easy. Instead, there are guidelines, tutorials, best practices, and checklists that all seem to conflict with each other in some way or another.

For this project, I went straight to the source, the W3C. I used a combination of their Web Accessibility Initiative (WAI) menu tutorial along with the WAI-ARIA Authoring Practices Draft to document forty-nine separate requirements for accessible menus. Then, I did my best to map those requirements back to the WCAG and identify which ones were optional and which were mandatory. Needless to say, it was a bit of a challenge.

Before diving into the technical details, though, I start by performing some practical “real world” tests for people with cognitive, ambulatory, and visual disabilities. This helps me identify the most critical issues right away.

I begin by simply checking the basic look and usage of the menu with my mouse, the way most people would use it on the desktop. I make sure it looks like a menu, smells like a menu, and acts like a menu. In particular, I make sure that any dropdown menus are easily identifiable and usable.

For people with low or compromised eyesight, things generally aren’t too hard. We check the menus at various sizes up to 400%, and we double-check that nothing relies solely on color to convey information.

For cognitive impairment, again, it’s mostly a visual inspection to make sure that menus, menu items, dropdown indicators, and other controls are all obvious and easy to use. Introducing a radial menu instead of a traditional horizontal or vertical menu, for example, might not go over so well. Similarly, for things like dropdown indicators and mobile menu buttons. We want to make sure that they follow expected patterns.

People with ambulatory impairments generally need to use keyboards or keyboard commands to navigate menus. Some people test keyboard navigation and screen readers at the same time, but I like to do them separately since some screen readers slightly change the behavior of the keyboard.

When testing keyboard navigation, I start by making sure I can use the TAB key to navigate into the menu with my keyboard and that I can skip past the menu using a skip link. I make sure that dropdown menus don’t automatically open when I tab to the top-level parent items, and I make sure that I can open and close the dropdowns using both the spacebar and the enter key. Inside a dropdown, I check that the Escape Key closes the menu and returns me to its top-level menu.

One of the most overlooked things with keyboard navigation is the mobile menu trigger, or hamburger button. Too often, we find that they work fine on mobile with a touch screen, but can’t even be targeted or opened with the keyboard.

Once we have tested the trigger, we now have to go through all those keyboard tests again for the mobile menu since those are usually coded and styled differently from desktop menus. Again, all the same issues and challenges apply.

Now that we’ve done all that, it’s time to turn on the screen reader and close our eyes. On a desktop, screen reader users will typically listen to the page being read and navigate the page using the keyboard. On mobile, they’ll do a similar thing but often use voice commands to navigate, which can be even trickier. I’m just going to go over desktop testing for today’s video, though.

Once we load a page, we want to listen for the navigation landmark to be announced, then we listen for the list and the number of items it contains. This helps screen reader users orient themselves to the location, structure, and size of the menu.

Then, we run through a similar keyboard test as we did above, only this time, we have to listen for clues telling us where we are and what we can do. In particular, we want to listen for indicators such as “current page,” “visited link,” and “submenu.”

Submenus are particularly tricky since we need to know several pieces of information. One, we need to know that there is a submenu. Then we need to know what state it’s in, whether it’s expanded or collapsed, then we need to know how to activate it. Once all that has happened, then we still have to navigate inside of it while still keeping our position on the top-level menu in mind. That’s a TON of mental energy just to use a menu.

What I like to hear, is a separate button being announced with the name of the submenu, so I know what the submenu belongs to and how to open and close it. In reality, only a small fraction of the menus behave this way. Most of them open with links on the top-menu items, so we never really know whether the menu is going to open, or whether we’ll end up following the link. Or, the submenu automatically opens when we tab to it, forcing us to navigate through it whether we want to or not.

Once we are inside a submenu, the challenges continue. Now, we are presented with another list of links that we believe are related to the parent item. The tricky part is getting out of the menu or knowing when we are back out of it and on the top level again.

Getting out and knowing when we are out is hard. The escape key should, theoretically, allow us to close the menu and get back to the top level, but again this only works a fraction of the time.

The other challenge is that the screen reader isn’t going to tell us when we have left the submenu by tabbing out of it. Luckily, submenus formatted as a list will tell us how many items there are, and we just need to count to keep track of our location.

I hope you are now starting to understand how easy it is to get lost in a menu very quickly!

Oh, and did I mention that we have to do all of this for both the desktop version of the menu and the mobile menu?

Good times!

So, how did the different menus hold up?

WordPress 6.0 did pretty well, with no major issues visually or with the screen reader. I especially liked that it uses buttons to activate submenus and identifies the labels top-menu items that hold the submenus. The only real issue I found was that I couldn’t close a submenu using the escape key, but that was fixed in the version 6.1 release candidate.

Elementor had a catastrophic failure, in that I wasn’t able to activate the mobile menu with my keyboard. It also had serious usability issues with dropdowns because of its non-standard behavior where pressing enter or space on the menu item once would open the submenu, but pressing it again would navigate to the link rather than close the submenu.

Bricks is so close, yet so far, and embodies the W3C statement that [“No ARIA is better than Bad ARIA.”](Read Me First | APG | WAI | W3C) They incorrectly attempt to follow the wrong menu pattern, and even then, they make a bit of a mess of it. Also, the settings for Bricks menus out of the box are very accessibility unfriendly.

From a keyboard navigation perspective, the big issues are, 1. you can’t use the escape key to close menus, and 2. dropdown menus only open with the space bar, not with the enter key as they are supposed to. The worst part, however, is that every top-level menu item has an aria-expanded attribute set, making screen readers announce all items as “expanded or collapsed”, regardless of whether it has a submenu or not.

Both of Oxygen’s menu types, the regular menu, and the pro menu, are a hot mess. In fact, using a keyboard, it’s impossible to activate dropdown menus at all making it completely unusable for both ambulatory impaired users and screen reader users. Oxygen doesn’t even use the aria-expanded or aria-haspopup attributes that allow screen to announce that a dropdown exists. To add insult to injury, Oxygen’s “pro menu” isn’t even wrapped in a Nav element, so screen reader users don’t even know that they are in a menu without guessing.

The worst offender of the bunch, however, is Breakdance. Calling it a hot mess is an insult to hot messes. They somehow decided that they didn’t need to follow any of the set patterns for menus and, instead, use plain old Divs, links, and buttons.

Some of the issues I found are 1. screen reader users have no frame of reference inside the menu, 2. submenus can’t be closed with the escape key, submenus automatically open when tabbed over them, forcing keyboard users to tab through all the items to get out. And it gets even worse for regular WordPress menus inside Breakdown. When the keyboard focus hits a dropdown, it just disappears. No dropdown opens, and nothing is read by screen readers, but somehow we are still forced to continue tabbing through all the invisible links before we get back to the top level and have to repeat this process all over again for the next dropdown.

Thankfully, things got better when I tested Generate Press. Out of the box, Generate Press uses hover to open submenus, which caused a lot of accessibility problems. Changing the menu setting dropdown arrows cleared up most of them, however. The only issue I found was that dropdowns didn’t automatically close when I tabbed out of them unless I pressed the escape key or opened another dropdown.

Kadence also did quite well, and it did it mostly without any changes to the default configuration. The biggest problem I ran into here was that the escape key didn’t close menus, so I had to tab through them to get out.

I had high hopes for Max Mega Menu since I’ve heard such great things about it. Unfortunately, it had a few failures that I didn’t expect to see. None of them are terrible, though. I had just expected a bit more from them. One issue I found is that the dropdown menus open automatically when you tab over them, but that isn’t terrible since you can close the dropdown using the Escape key. The real shocker to me was that the menu doesn’t identify which page you are on like typical menus do. Other than that, though, there were no major practical issues.

And lastly, how did my own menu fare? In the practical tests, it did pretty well. Just like Generate Press, however, my dropdown menus don’t close when I tab out of them. And, as with Max Mega Menu, I don’t set the aria-current=”page” attribute, so my menu doesn’t announce the current page. Other than that, though, the problems in my menu are mostly technical and don’t have any major practical ramifications.

So that’s it in terms of the practical tests. For the technical tests, I had to dive into the structure of each menu’s elements, their attributes, their styles, and their behaviors. Don’t worry. I’m not going to subject you to a video of me painstakingly going through each checklist for every menu type. What I will do, though, is show you what works well and what needs improvement for each one, along with any critical problems that I found. I’ve also scored each one based on how well they perform and adhere to accessibility standards, so you’ll see the results of all that work in the next video.

For now,

Let me know your thoughts, ideas, and opinions in the comments below.

And, as always, if you found this video helpful, please hit that like button and subscribe to the channel.

I’ll see you next time!