More WordPress Menu Accessibility: Four More Menus Compared

Today I’m going to test four more WordPress menus for basic accessibility issues. If you missed last week’s video, where I tested ten menus and gave an overview of their accessibility challenges, I suggest going back to that now. I’ll drop a link to it in the description below.

Shortly after releasing that video, I had a lot of people reach out asking me to include their favorite themes and builders. So here it is, Part 1.5, where I’ll test Beaver Builder, Divi, Astra, and Cwicly. I’ll also take a few minutes to answer the questions or respond to some comments that people left in different places.

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, click that subscribe button, or leave a comment. If you are feeling extra generous, you can even do all three!

For the sake of time, I’m not going to give an overview of my testing method, accessibility, WCAG, POUR, or any of those things that I already covered in Part 1. Again, the link is in the description, so watch that one and come back when you are done.

Here are some of the comments and responses that I wanted to share with you all:

• First, I’ll answer the big question. Yes, I will share my criteria and findings with you. When I publish the Part 2 video, I’ll include a link to view everything. I considered doing it sooner, but I want to make sure that everything makes sense and is accurate. I don’t want to be a spreader of misinformation.
• I had several people ask me to share steps to create an accessible menu. I didn’t want to commit to anything out loud, but I do plan to do one in a few weeks. It’ll probably be shortly after I present my full results in Part 2 of this series. I had originally wanted to just update my existing menu, but now I’m thinking that I’ll re-work most of it from scratch.
• Tom from GeneratePress reached out to me and thanked me for pointing out the issues. Apparently, he has a release coming out in the next few days, and he said that he’ll be addressing these menu things right after that. He’s always taken accessibility seriously, and I’m glad to see that he’s on top of things.
• Several people have reached out to Bricks with bug reports and forum comments. I look forward to seeing the changes they implement.
• Elementor has a few long-standing forum comments and bug reports about their issues. Either they don’t care, or they haven’t figured out how to fix their problems yet.
• All is quiet from Soflyy, the makers of Oxygen and Breakdance. Maybe that’s because everyone is afraid of getting banned in their forums for pointing out their flaws. Come on, guys, you had so much going for you, but now it’s just one PR issue after another.
• There have been a few comments about Max Mega Menu, especially since it’s regarded in the accessibility community as one of the best solutions around. Generally speaking, I agree. And, like I said, the issues I found were minor in the grand scheme of things. I’m mainly surprised and disappointed to see that the issues it did have were so obvious and seemingly easy to fix.

Now, let’s get into the new tests.

First up, we have Divi. This one… I knew it was going to be rough before I even started, and it didn’t disappoint. Doing these tests really was like watching a train wreck in slow motion.

For this test, I have a blank WordPress installation with Divi and some theme test data loaded. Off the bat, I can see that the menu contrast fails miserably. It should be 4.5:1, and this is 2.81:1. The next thing I see, is that the menu items get even lighter as I hover over them. Not only does this worsen the contrast, but it also goes against the WCAG standard of needing a non-color representation of a state change.

It gets even worse when I try to use keyboard navigation. There is no skip link in the theme, and there is no indicator at all of where I am in the header. In fact, as I tab through, the only thing telling me that I’m doing anything is the link bar at the bottom of my browser.

When I try to test opening dropdowns using my keyboard, I get another failure. Neither the space bar nor the enter key will open the dropdown. This makes the menu completely inaccessible for both keyboard users and screen reader users. Moving to the mobile menu trigger, we have yet another failure. Divi does not let us focus the keyboard on the mobile menu, so it’s also totally unusable.

Lastly, when I turn on my screen reader, I can hear that Divi doesn’t announce the presence of submenus. It only lets us know about the top menu items. That’s because Divi isn’t using the correct aria attributes that either says that a submenu is there, or indicate it by saying that a submenu is expanded or collapsed.

Next up, we have Beaver Builder. I haven’t used Beaver Builder in many years, but I used to think highly of it as a product. I’ve heard, however, from various accessibility testers that it’s been known to have problems. Beaver Builder users counter that they have been trying to address them, so I was eager to give it a test.

Unfortunately, the rumors were right; It’s still not very accessible.

To start, there were contrast issues with the theme and menu right out of the box. Of course, this is something that can be easily changed with settings, but it’s also something that should be easy enough to get right in the defaults.

Again, looking at the default settings, there are no indicators of hover states or the existence of dropdown menus.

On our keyboard tests, there was no skip link at the top of the page. Then, the keyboard focus jumps from the site icon on the left side of the page to the search icon on the right side before coming back to the center with the menu. Tabbing through the top-level menu items automatically opens the submenus. That’s not terrible, but it fails the “Recognizable” criteria of WCAG’s four areas, Perceivable, Operable, Understandable, and Recognizable. Also, the escape key doesn’t close either the dropdown menus or the popup search bar.

The weirdest thing was when I tried to tab backward through the content. Here, the submenus and search box stayed open and overlapped each other. Making it even stranger, the bottom item in the dropdowns didn’t get focus when shift-tabbing.

The other keyboard issue was with the mobile menu, where I could correctly open and close the menu itself, but I couldn’t open or close any submenus.

Using the screen reader, Beaver Builder wasn’t announcing either the presence of submenus or that menus were expanded or collapsed. Looking at the code, I could see an aria-popup=”true” attribute, but it was on the list item instead of the anchor, which in this case, is the targetable dropdown trigger.

That’s enough of Beaver Builder. I do like that they are making an effort toward accessibility, but clearly, they still have work to do.

Now we come to Astra. Brainstorm Force, the makers of Astra, have a long history of quality products, so I expected good things from them. I was truly shocked at how poorly it performed, though. And, I was even more shocked when I looked under the hood to find that they actually had all the right pieces in place; they had just put them in all the wrong places!

Starting with the visual tests, Astra’s menu failed color contrast out of the box. Again, though, that’s an easy enough fix in the WordPress customizer. Hover states didn’t meet accessibility criteria, but I’m not even surprised by that anymore.

Keyboard focus indicators do seem to work, so that’s better than some of the products I tested in this video. Dropdowns do automatically open when the keyboard focuses on their top-level menu items, so that’s a bummer, and the escape key doesn’t close the menu, which forces us to tab all the way through them. I didn’t see any obvious ways to change this behavior in the Astra settings, even when I checked the Astra Pro Nav Menu settings.

In the screen reader tests, the Astra menu failed to tell me about the presence of dropdowns or their states. It wasn’t until I got into the submenus that I could hear that I was suddenly in another menu, so I had to infer that I was in a submenu.

Looking at the DOM showed me all kinds of strange things.

First, the UL element had an aria-expanded=”false” attribute for some reason. According to the W3C, aria-expanded should only be on the button element or another targetable element that controls dropdown behavior. In this case, Astra has it on the UL element, which does nothing.

Next, there is the LI element with aria-haspopup=”true.” Again, just like the expanded attribute, this one needs to be on the controlling element, which in this case is the anchor, not the list item. That means that our screen readers will never even see this aria attribute or let anyone know that there is a popup.

Coming down, I can see that there is a button element, which got me excited since I normally like button elements on menus. However, for some reason, this is only targetable on the mobile menus and is completely ignored on the desktop menus.

I was even more shocked to see that the button element has hidden screen reader text saying that it’s a menu toggle, so the fact that they did that for the mobile menu and ignore it on the desktop just makes no sense to me.

Watching the actions when the dropdowns open and close also baffled me since nothing seemed to make the aria-expanded attribute change along with the dropdown state.

So, unfortunately, in its current state, I have to give low marks to Astra for accessibility. It’s like an expert marksman got to the range and started shooting at someone else’s target instead of his own. I just don’t understand it!

Lastly, I’m going to end these tests with one of the newer themes on the block, Cwicly. This is one of those tools that has a ton of power behind it and has grown immensely in the year or so that it’s been out. When I first took notice of it, I thought it was basically a technology demo. Now, however, I hear a lot of people singing its praises as being the most advanced Gutenberg-based tool on the market. That may be the case, and I may just not know what I’m doing, but these tests reinforced my perception that it’s still a tech demo at this point.

The first thing to note is that Cwicly menus have no styling out of the box. They are simply a list of items with some built-in logic to show and hide submenus. To make them even remotely resemble a menu, we have to do that on our own, as I’ve done in this second row.

It’s also worth noting that, in Cwicly, you’ll need to create your own submenu button and mobile menu panel. I’m fine with that and appreciate the control and flexibility it offers, but as you’ll see later, Cwicly gives you a to of options for the way things look, but not necessarily the way they behave.

For mouse tests, everything worked as expected. Out of the box, the Cwicly menu did nothing, but it could be configured to do pretty much anything I wanted. The same goes for keyboard focus states. I could make the menus, menu items, and submenus look however I wanted.

In my keyboard tests, this is where the issues started to crop up. Nothing I did with the keyboard would trigger the dropdown menus. Not the space bar, not the enter key. Hovering over them with the mouse worked fine, but using the keyboard was a no-go.

Turning on the screen reader, it got even worse. First, there was no skip link, then there was no indication that a menu was present. As the reader went through the list, it also failed to announce the presence of submenus or their expanded and collapsed states.

Digging into the DOM, I could see that the menu was not wrapped in a NAV element; it was just sitting inside a div in the header. That explains why the screen reader didn’t alert me that it was a menu. I also noticed that there was no aria-current=”page” attribute to tell me which page I was on. In fact, there was no aria markup at all, which is why my screen reader couldn’t tell me about the dropdowns.

I may have missed something, but I couldn’t find anything regarding aria attributes anywhere in the builder, the documentation, or the forum. This is a HUGE problem and really does tell me that, at least right now, accessibility doesn’t seem to be on Cwicly’s radar.

Alright, that’s all I have for now. These tests left me thoroughly depressed.

Next up in this series, I’ll go deeper into the testing criteria and show you all the places where these products did well and where they need to improve. I still haven’t figured out how to present it without putting everyone to sleep, so that’s the biggest challenge I’m facing right now. I hope to get that video out sooner than later, though, and I’m going to try my hardest to do it within the next seven days. We’ll see if that sticks!

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!