Navigating the Future: Using WordPress Menu Blocks That Work for Everyone: Jennifer Dust and Eli Frigoli

>> AMBER HINDS: Welcome to WordPress Accessibility Meetup, Navigating the Future: Using WordPress Menu Blocks That Work for Everyone, with Jennifer Dust and Eli Frigoli. A few announcements if you have not been before. We have a Facebook group that you can use to connect with other attendees between meetups. If you go to facebook.com/groups/wordpress.accessibility or just search WordPress Accessibility on Facebook, you can find it. It’s a good place to share what you’re working on, get feedback, help other people, and just generally chat in between meetups.

If you are interested in finding upcoming events or the recordings everyone always asks and we probably will get this question later on. Yes, this is being recorded. It takes us about two weeks to get corrected captions and a transcript and all of the notes and things from our speakers, and then we will post up that recording. You can find all of these things if you go to equalizedigital.com/meetup.

The other way to get notified when the recap is available is to join our e-mail list. You get news and event announcements if you sign up at equalizedigital.com/focus-state or focus-state. Then if you want to listen to the audio, these are being released in podcast form at request of some of our attendees. Those can be found on accessibilitycraft.com in combination with our podcast that myself and my partners, Chris and Steve, put together where we talk about craft beverages and web accessibility, which is super fun.

We are seeking additional sponsors for the meetup. It is part of the official WordPress meetup program, but they told us that they did not have the funds to help cover the cost of accessibility for meetup. They said, “Go out and find sponsors.” Anyone who is helping or interested in helping to make the meetup accessible for our attendees through captions or transcription, we very much appreciate that. Please reach out to us.

If you have any suggestions for the meetup, if you are interested in speaking, I will say that we are still looking for some speakers, I think, as early as March potentially for our Monday– For me in the US, it is Monday at 7:000 PM Central Time. That meetup, we have a few March, April, May, I think, openings there. We’re looking for speakers. Anyone who’s interested in speaking, please reach out. If you need any accommodations to make the meetup work well for you, we would love to hear from you and are happy to help. You can contact myself and Paula at meetup@equalizedigital.com.

Who are we? I am Amber Hinds. I’m the CEO of Equalize Digital, who is the organizer of this meetup. We are a mission-driven organization and a corporate member of the IAAP. We are focused on WordPress accessibility and have a WordPress plugin called Accessibility Checker that scans for accessibility problems and provides reports on the post-edit screen with the goal of making building accessible websites easier.

I’ve said our website a ton of times, so I won’t say it again. We are on social media. We’re generally @equalizedigital. We’re on Twitter and LinkedIn and all of those things if you want to find us there as well. We do have a sponsor that I want to thank today, Kinsta. Kinsta provides managed hosting services for WordPress. It is powering 120,000 businesses worldwide. Based on the user reviews, it is one of the highest-rated managed WordPress hosts on G2.

Kinsta has everything you need, including an unbeatable combination of speed, security, and expert support. It is powered by Google Cloud and the fastest C3D and C2 servers combined with CDN and edge caching. Your sites are secured with Cloudflare Enterprise, protecting you from DDoS attacks. All plans include free migrations. The first month of starter plans is completely free, so you can always try out Kinsta completely risk-free. Huge thank you to Kinsta for covering the cost of our live captioning today.

We always encourage our attendees to say thank you to our sponsors because, one, it helps to tell them that I did what I said I would do during meetup. Two, it helps them to know that their sponsorship and the captions that they help provide are valuable and that people appreciate them. You can learn more about Kinsta if you go to Kinsta.com. You can find them on X @kinsta. They’re on many other social media platforms. Wherever you are most active, if you are willing to tweet them or send them a message just that says, “Hey, thanks for sponsoring captions for WordPress Accessibility Meetup,” we very much appreciate that. It is helpful.

I have two upcoming events that I want to let you know about. The next one, nerdy me is so excited about this talk. [chuckles] It is how D&D, which is Dungeons & Dragons for people who are not familiar, which is a tabletop game, role-playing game sort of, can improve accessibility. How D&D Can Improve Accessibility: Using Roleplay During All Phases of Product Development to Better Consider User Experience.

Our speaker will be Nick Croft, who’s spoken a couple of times for us before. It should be a phenomenal presentation. That will be on Monday, January 20th at 7:00 PM, Central Time. Then on Thursday, February 6th at 10:00 AM, Central Time, which is the same meetup time, we’ll be back to our normal first Thursday of the month. We will have Chris Scholtens presenting Digital Accessibility: Thinking Beyond WCAG and Compliance.

I am going to add some spotlights here for our presenters. Today’s speakers are Michaela and Eli. Oh no, we missed changing the heading. Sorry, Michaela was going to present, but she was ill. Jennifer, we’re so excited to have stepping in. Sorry about that, Jennifer. [chuckles] Jennifer is the senior manager of DevOps at Aten Design Group. Jennifer is an Acquia-certified senior manager of DevOps with several years of experience using Drupal and WordPress. She holds two master’s degrees. One in computer science and the other in business administration with a focus on project management.

Eli is a senior WordPress developer at Aten Design Group. They have a Bachelor of Arts in Digital Design and a Bachelor of Science in Computer Science. Eli is an experienced WordPress developer excited about building dynamic, interactive websites. Eli has a background in software and front-end web development and is passionate about creating accessible user experience.

Thank you so much, Jennifer, for stepping in. Welcome to both of you. I am going to stop sharing my screen. I’ll let you take over. A quick note for our attendees before I hide myself. There is a Q&A module down at the bottom of Zoom. If you have any questions for our presenters as they’re presenting, please put those in there and I will come back at the end of the session to pass them along. Thank you.

>> JENNIFER DUST: Oh, I’m going to take over now. Hopefully, y’all are seeing my screen here.

>> AMBER: Yes.

>> JENNIFER: Sounds great. Okay, so thanks, everybody, for attending. We’re super excited to be presenting Navigating the Future: Using WordPress Menu Blocks That Work for Everyone. As she mentioned just a few minutes ago, my name is Jennifer Dust. I’m the senior manager of DevOps here at Aten Design Group. My background is in higher education and working with non-for-profit organizations. I’ve had the privilege of working in the open-source community for well over 15 years and both Drupal and WordPress. I’m also a disabled human, so I’m really excited to be presenting on accessibility today.

>> ELI FRIGOLI: My name is Eli Frigoli. I am a senior WordPress developer with Aten Design Group. I really deeply enjoy leveraging WordPress to build impactful, dynamic user experiences that are accessible to everyone.

>> JENNIFER: Aten Design Group, where we work, is a full-service digital agency that’s been around for more than 24 years. We provide digital strategy, design, and open-source development for mission-driven organizations all over the world. We’ve worked with a number of governmental, higher education, and non-for-profit organizations like the Smithsonian, Stanford University, Human Rights Watch, and more. We’re passionate about partnering with organizations to tell their important story and honestly doing work that matters.

Let’s actually get to what we’re talking about today. It’s important to know how to test your website. If you don’t know what the issues are, we can’t fix them, right? Seems pretty straightforward. We’re going to actually talk about doing automated testing first. This is the tools that are going to comb through your code to identify specific issues. A lot of these are going to be things that are difficult to find in the code itself and typically can’t be seen by just looking at the front end of a website.

That’s things like insufficient color contrast, incorrect heading structure, vague links, missing form labels, and images without alternative text, and many more. These are things that you’re really only going to find if you’re looking in the individual code pieces. Now, keep in mind that the results from automated tests can give us false errors. It’s just a piece of software that is following specific expectations and doing what we’re asking it to do.

It’s a great place to start, but we’re going to dive in later. Human logic always needs to be applied to when reading these reports. Kind of false errors frequently show up. We’ll see them in contrast. We’ll see them in elements that the software might think is headings but isn’t actually. That’s why we always need to review these things. The first two that we’re going to talk about, we typically employ, we have WAVE and axe DevTools.

Axe DevTools is a developer-friendly toolkit. I’ve got on the slide their URL where you can access that at deque.com/axe. That’s A-X-E. It can be integrated into your dev workflow. Some of their tools are code linters to service potential issues directly in your CLI and a browser extension for automated page testing. This is really, really helpful when you’re looking in leveraging native browser inspect tools. For the sake of keeping this presentation a little bit more beginner-friendly, we’re going to focus primarily on WAVE’s automated capabilities. If you’re a dev seeking to integrate this testing, I would recommend definitely taking a look at axe accessibility tools.

If you’re new to automated software testing, I recommend taking a look at the WAVE plugin. They’ve got a website at wave.webaim.org. It’s a great extension that you can add into Chrome or Firefox if you use either of them. The cool thing with this is that it allows you to test or extend sites that might be behind a login. It gives a fairly clean overview of what kind of errors and warnings might be found in your code. Again, I just want to call this out that this is a starting point. It’s also a great resource for learning WCAG standards besides what’s required in ADA compliance. The information that they provide along with the errors is a little bit more human-readable than some that I’ve worked with in the past.

We’re going to walk through an interpretation of WAVE results. I’ve got the ESPN website here. It’s already been run through the WAVE checker. There’s icons all over showing lots of different errors, alerts, notifications, along with accessible ARIA landmarks. On the left-hand sidebar, WAVE is displaying a summary of those results. Within the page and the content of the right, we see the presence of all those accessibility errors. Those are what I highlighted earlier, the alerts, features. Those are all represented by individual stylized icons. There’s a lot happening on this website.

WAVE provides a toggle in the toolbar that’s going to help us disable these styles. Often, it’s easier to interpret these results with styles disabled. It makes things easier when we’re checking where headings are appearing. The red icon status is going to stand out more clearly against plain text. Turning off the styles also gives us a better idea of how screen readers will experience the site since we’re focusing on semantics, on structure and flow, rather than just focusing on the styling.

Opening the Details tab in the WAVE’s tools is going to allow us to really zero in on these errors and features that are within the code itself. By clicking on any of the icons in the left-hand toolbar pane, we can actually scroll in that page location to where that element is and it will outline it for clarity. Whenever possible, WAVE’s going to try it and give you an explanation of what those errors might be.

If we click on the Reference link, the icon’s going to open up the Reference tab and allow you to dive deeper into the accessibility standards for solutions. In an example here, contrast provides some detail about the level of contrast between the color and the foreground and the text against what’s in the background. Oh, that was my next slide. WAVE has a dedicated tab for color contrast checking. Here, I’ve got, the color contrast is opened.

We can see detecting the two different colors between the foreground and the background example. It provides a ratio score and showing whether or not it passes the WCAG AA or AAA testing thresholds. In this instance, it’s passing neither, so not great. The WAVE tool also provides sliders for you to play around and adjust those colors in real-time to see what those acceptable ratio thresholds might be. You could probably get away with tweaking to see where you could make those adjustments.

The other tools that I want to highlight is the Structure tab. That’s what I’ve got open here on the left. It’s showing the semantic structure of the code outlining based on page headings and other semantic elements. For instance, I’ve got header and then H2, ESPN, H2, favorites, and then navigation regions. This can identify any kind of structural issue like seeing multiple H1s within a page or incorrectly configured navigation elements.

The code viewer is an expandable pane at the bottom of the page. That’s going to display the raw HTML that we’re seeing generated on the page. It’s a similar function to when you go in and open developer tools. It provides you an opportunity to view the code itself. While clicking on those errors in that left-hand panel, it’s going to highlight those when that code bar is open, showing you the relationship between what’s actually being called out. There’s a lot of really great tools within WAVE, so I recommend doing some testing on your own and playing around with the toolkit to get an idea of what the power of automated testing really is.

Okay, that’s automated testing at a high level. Let’s actually take a look at where I like to be, which is mostly manual testing. There’s a lot of users who rely on keyboards to navigate websites such as visual users who don’t want to use a mouse or able-bodied users who find it easier to interact with keyboard commands. Because of that, anybody can test a website using just their keyboard. The good thing is, if your keyboard can interact with something, then your screen reader or other assistive tech user should be able to as well.

If you can’t interact with something using your keyboard, then a screen reader also can’t, which is really important why I’m making sure that a keyboard user can interact. Your site works with a keyboard first as a great step. Just a quick note, I did want to call out that some browsers require you to turn this on. If you’re running into an issue where you’re testing and you can’t get your browser to interact using Tab or through your keyboard, go to your browser preferences and make sure that the accessibility options are selected. I know we’ve run into this issue specifically with Safari in the past. They may have fixed it, but just wanted to highlight that.

How do you navigate with your keyboard? I’ve highlighted the primary keys here that we’ll be using for testing. These include Tab, Shift, Escape, space bar, Enter, and the arrow keys. Keep in mind that keyboard users only Tab to interactive or elements within the tab flow. What I mean by that is the order of things that come into focus on the page. Ideally, you’re not ever going to be tabbing to headings or paragraphs, unless these are also linked within the content. A lot of the times, assistive tech users, we can swipe in and it will read those or let us focus on those however we’ve set up.

Starting with one of the most commonly used is Tab. This is the key you’re going to use to move forward through your site. If we want to move backwards, we’re going to move back at the tab flow by using the Shift + Tab key combination. To close dropdowns, any type of pop-up videos or mobile menus, that’s when we want to be able to leverage the Escape key. Arrow keys are used a lot when moving in forms between radio buttons, checkboxes, as well as navigating carousels, select menus, and in more recent years, menus themselves, navigation menus.

If you’re interested, if you’re interacting with something and you can’t seem to get to it with the Tab key, try testing out the arrow keys instead. Last, we’ve got both Enter and space bar. These are for users who are interacting with buttons, checking radio buttons and checkboxes. Now, we’ve got a high level of how each of these buttons is intended to work. I’ve got a quick checklist that we’re going to walk through here.

The first one being, can you interact with your site? For example, you’ve reached your menu or a specific interactive element within your page. Can a user actually engage with it? Then you want to check your focus styles. There’s that blue, sometimes stylized outline you see around the content. Does it display when you are on or focusing a specific element? Sometimes websites turn these off. That’s one of the worst things you can do because we are relying on those.

The next thing is, is that interaction expected? For instance, did you go to a slideshow and move through with Tab or arrows? Is it actually moving or is it doing something weird like it’s jumping to a different element that you didn’t expect it to get to? If your site has modals, pop-ups, or carousels, can you access them? Can we navigate within them? Most importantly, can we close them? Does that Escape key work? Can I close that content and get to the rest of your site? Can we navigate forwards as well as backwards through your site? If I tab over and I’m on your article page and I’ve tabbed too quickly, can I Shift + Tab backwards to get and read what I wanted to get there?

I’ve got a short example clip here. This is a video that is providing an example of a user tabbing through the header on our homepage. In this short clip, we can see that there is a blue outline focus state that’s showing up around the logo and each menu item, including search. While you can stylize the focus state to match your design or brand, ideally, we want to leave it default since that’s the best-case scenario. A lot of assistive tech users have software that customize these interactions or for our individual needs.

Going back to our list with interacting when we’re testing here is number six. This is a big one. Hovering content should not be the only way a user can access it. There needs to be a way for keyboard users to toggle that content open and close just through the keyboard. No requirement on the mouse. It’s also really important to check your mobile menu. A lot of the focus sometimes ends up being on desktop, but we’re still users on mobile devices. Can a keyboard or assistive tech user interact with each item, including opening and closing menus, nested structures, and along with the whole menu itself?

Websites should also have a visually hidden skip link at the top of the page for the navigation and main content. First is, do these exist on your site and can you interact with them? Then when tabbing through your page, does the flow of the tab sense make sense? Are we following what’s on the page in a logical order? A good rule of thumb is that if you can interact with your mouse, you must be able to interact with your keyboard. I’ve got another video example here of a user interacting with a skip link at the top of the page.

They’re able to click into it and skip over the header entirely, so that’s our navigation, right into the main body of the content where you’re seeing human-centered strategy, which is strategy being a link. We often see these links when reviewing sites, but a lot of the times when I’m testing them, nothing happens whenever we try to interact with them. Skip links are used to skip content or highly interactive content, right? Videos, interactive embedded, iframes, maps, sometimes social media embeds, because those experiences are pretty frustrating when you tab into them as a keyboard user. All of which, since they have those interactive elements, it’s just a challenge to get to some of the other content.

We’ve taken a look at automated testing and keyboard testing. Now, I want to talk a little bit more about reviewing your site manually. This is where we’re going to confirm those false errors that I mentioned earlier during the automated testing and structural issues that might have come up in other portions of your review. We want to apply our human logic and flag anything that just doesn’t seem right or that’s probably a false error.

Color is not going to be the only means of communicating important information to your user. Those who are colorblind need to have other ways to distinguish information. This also goes for non-visual users as well. If you imagine that your website’s being printed in black and white, can a user still understand what’s being displayed? If not, then you probably need to add text or patterns alongside the color.

At the bottom of my slide here, I have three different pie charts. There are a grid with three. We’ve got apples, oranges, and I think it’s bananas. There are different variations of red, orange, and yellow. The left relies just on color. The middle and right, so the other two, have had their color saturation removed to show the difficulty of only relying on color and how hard that is to differentiate. If you asked me, I wouldn’t be able to tell you the differentiation between those colors.

We’ve added a pattern in the far right chart where you can see the apples, bananas, and oranges all have patterns. I’m not relying on color to know what that content is actually relating to. We also want to review if the target area someone is expecting to interact is big enough. What I mean by that is the actual pixel size of the click area when someone’s pressing on something. With the release of WCAG 2.2, that requirement actually changed so that the new minimum or the AA standard is 24 x 24 pixels.

I actually prefer and recommend using the AAA requirement, which is 44 x 44 as your minimum size. We want all of these interactable pieces of content, so think menu icons or the social media icons or checkboxes or other form elements within your site to fall within these dimensions. A big difference you’re going to see on mobile devices too, especially, I don’t know if anyone struggles like I do on mobile devices to try and click on things. When they’re bigger, it’s a lot easier to make that hit target.

We also want to review the content and imagery within the site. Does it have alt text and is it useful? What I mean by that is all the information in an alt text is provided to screen readers, which means you want to keep it short and to the point. It’s really, really frustrating when things get read out to you. It’s just over and over logo of, image of, and it’s not really helpful. Alt text should convey the content and function of the image within the context of your content. What I mean by that is that if you have images or icons that don’t provide additional information or just visual enhancements, you should probably have an ARIA hidden as true on those.

A good example would be describing a room for images in your bed and breakfast. You’ve got a bed and breakfast. You’re describing what the room might look like in that image because, as a user, I want to book this hotel versus stylized icons that are on your webpage. They don’t necessarily add to the meaning of your content. Lastly, please don’t ever do this. Don’t use SEO keywords within your alt text. It’s bad practice and it’ll have a negative impact on your Google ranking. That’s a lot. I’m going to stop for a second and I’m actually going to hand this over to Eli so they can now dive into the WordPress menu options.

>> ELI: Thank you so much, Jennifer, for that overview. Now that we have the background information about how to test websites for accessibility, let’s actually take a look at WordPress menus to see how different menu solutions measure up to accessible standards. When it comes to building WordPress menus, there’s a few common tools that most sites rely on for their menu structure. Let’s take a look at two of the most common options and evaluate their strengths and shortcomings.

In modern WordPress sites compatible with block themes, WordPress core provides two blocks used to build navigation menus. The page list and submenu blocks. Both of these blocks facilitate the creation of submenu dropdown items within the site navigation. However, there are some drawbacks to leveraging these core blocks without any modification. The capabilities of navigation menus built through these blocks are limited to more barebones functionality. This presents significant challenges when attempting to navigate via keyboard.

First, the menu can only be navigated through the Tab key with no arrow key functionality present. Fully accessible menus should allow users to navigate by both Tab keys and arrow keys with the left and right arrows navigating to top-level sibling items and the up and down arrows to navigate through any present submenus. The tab flow is also inconsistent with these core blocks. The tab flow is not in alignment with the visual order of menu items on the page. Once menu items are expanded, it is not visually clear which direction the tab flow is moving through their submenus.

Finally, all menus will collapse once the Escape key is pressed. This can be a frustrating experience for users navigating by keyboard as it not only closes all open menus, but it also doesn’t return focus back to the parent item. Ideally, the Escape key should only close the currently active submenu and return focus back to the parent menu item. This makes the user’s current position in the page tab order clear.

In this screencast, I am navigating through a menu I built using the page list block and the WordPress 2024 theme. This is built with no customization or manual styling. As I attempt to navigate, I am able to tab between the links. When I attempt to navigate into a submenu using up and down arrows, it instead shifts my entire page up and down. Once the second level of the mega menu is expanded, the tab order becomes visually confusing as the flyout appears to the left. It becomes difficult to interpret where I am navigating the menu.

While navigating within the second level of the menu, I press the Escape key. Instead of returning focus to the first-level parent item, the entire menu collapses and visual focus is lost entirely. Since WordPress core menu blocks provide only that barebones mega menu functionality, many third-party plugins exist to give users an easier interface for building their mega menus on their site. However, these plugins run many risks when it comes to accessibility.

First, the code may not be vetted or tested for accessibility at all. This is especially true of plugins that receive little support or ongoing maintenance. This is why the automated testing and manual testing steps that Jennifer outlined are crucial for sites that leverage third-party mega menu plugins. Even plugin solutions that claim to be accessible may not actually be accessible.

The level of WCAG compliance is completely up to the plugin author’s discretion. This means that even widely used and well-supported accessible menu plugins may still need to be thoroughly tested through both automated and manual tools. In our experience, even the most compliant third-party plugins still do require code modifications through the use of JavaScript in order to be fully accessible.

Not only are these modifications pretty complex and require familiarity with coding, but the modifications are not going to be applied to the menu at all if a user disables JavaScript in their browser. These modifications also run the risk of breaking if the plugin’s core functionality ever changes, which means that more time will be needed to thoroughly test the menu after any plugin updates.

In this next screencast, I am navigating a menu that we built for the city of Oxnard using a highly-rated plugin currently in use by over 500,000 WordPress sites. However, the menu still falls into several common pitfalls of inaccessible structures. The navigation elements do not have labels, which leads to confusion since there are two separate menus on the page. The utility navigation and the primary navigation.

I attempt to navigate these menus using arrow keys, but the up and down arrows move the entire page. Left and right arrows do nothing on top-level items. Once inside a submenu, the left and right arrows, they close a submenu and do not return any visual focus to a previous or next top-level item. Pressing Escape while on a top-level item with an open menu does nothing. Pressing Escape while inside a submenu closes all menus on the page and does not return visual focus anywhere. This makes keyboard navigating a confusing, inconsistent, and very frustrating experience.

In the following screencast, I’m navigating the same menu after nearly 300 lines of custom code were added in our child theme to modify its behavior. The navigation elements are properly labeled for screen readers to provide context to users. The mobile menu navigation span has been converted into a button for improved HTML structure. The Escape key now closes only the currently open submenu and the top-level items are navigable through left and right arrow keys. Up and down arrow keys navigate their submenus. After considerable modifications, this menu now functions in a more accessible way.

You might be thinking, “Well, if the core blocks aren’t fully accessible but neither are plugins, what do I do?” It’s a little more complex than a right or wrong option. Not every third-party solution is built the same. Some may have higher levels of accessibility than others right out of the box. If you’re looking to implement a mega menu plugin or if you already have one and you’re not sure what level of compliance you’re at, here are some practical steps for evaluating plugin solutions.

The official documentation will always be the best place to start. A well-documented plugin or theme may include a special section of documentation around accessibility standards and how to use their tools in a way that is accessible. The level of detail and documentation can vary widely based on the developers who built it however. Not every plugin or theme will have a dedicated library.

The next place to research is going to be the README file. Plugins will include usually at least a README file located in their root file directory with details about the functionality and how to utilize it. Look for mentions of accessibility or compliance with WCAG standards. If it’s still unclear whether the plugin was built to be accessible, check those changelogs for any mention of accessibility features such as adding ARIA or improving keyboard navigation. This will indicate that the plugin authors are keeping accessibility in mind as they iterate and improve their products.

If the changelogs and release notes are also lacking, the next best place to look is support forums. Users will frequently reach out to developers via support forums to request features or highlight roadblocks to accessibility. These support threads will provide a starting place for locating the pain points in a product and give a clearer perspective of the plugin’s level of compliance. They will also provide the opportunity to assess the development team’s response to feedback regarding accessibility with their products.

Finally, rely on the community around you. Reach out to ask questions not only to the plugin’s developers but to other developers who are using the plugin. Chances are, if you’re struggling to understand their accessibility standards, other developers in the community are as well. Next, inspect the code. Open plugin files and look through the output code for semantic HTML elements such as a navigation element to wrap the navigation and button elements used to toggle menus and submenus.

These elements help users utilizing assistive technology to understand and navigate the menu and reach the information that they need. Look for proper usage of ARIA on elements such as buttons, which should denote through an ARIA-expanded attribute whether their submenus are currently open. This helps communicate more information to assistive technology to help users access nested levels of submenus. A key principle to keep in mind is that no ARIA is better than bad ARIA. It’s important to evaluate the code, not just for the presence of ARIA, but for the proper application of it.

Finally, ensure that roles and labels are in place for screen readers. The structure of truly accessible code should rely first on appropriate semantic HTML elements, then on ARIA attributes being applied for context and assistance to screen readers, and finally, roles for any element such as a tooltip or a standalone icon for which no semantic HTML tags currently exist.

The final and most important step is going to be testing functionality thoroughly. Install a plugin on a sandbox or a development site and perform both automated and manual testing using the tools and steps that Jennifer outlined in the first half of this presentation. This will give you a good idea of whether your mega menu plugin is truly accessible or what steps you might need to take to modify the front-end code to become accessible.

Okay, so you’ve evaluated your third-party plugin. You found some areas that could use some improvements or maybe you’ve realized that you want full control over the menu structure to ensure that it’s accessible from the ground up. Let’s talk through some common modifications that we’ve frequently made to improve WordPress menu accessibility. Now, to build an accessible menu structure from the back end, we frequently leverage a custom Nav Walker class.

Custom Nav Walkers are classes based on the WordPress core Nav Walker class. They customize the output HTML structure of a WordPress menu object. Custom Nav Walker classes are going to be the best method for controlling navigation structure in WordPress because they rely on core functionality, adhere to best practices and code standards, and provide an accessible semantic structure from the ground up.

All right, this may look very scary, especially if you’re not used to using a Nav Walker class. This code example provides a full Nav Walker class. We’re going to walk through what changes we can achieve through the PHP on the back end to build our menu structure using accessible HTML. Do not worry if this seems like a lot or if it’s overwhelming right now. We will be posting all of our code snippets as part of our recap following the presentation. Anyone interested will be able to test them out and play around with them to really start to understand how to build accessible structure in your menus.

We begin by extending the core WordPress and Walker Nav Menu class. We want to extend it rather than using the current Nav Walker that WordPress provides so that we’re able to customize the output in a safe way within our child theme. We extend the class and then we’re going to use the public function start element. This function will take every single element within a WordPress menu object and allow us to control the output.

We instantiate a variable to contain our output. To it, we’re going to wrap each item in a semantic list item. We can keep all the same classes that WordPress provides by using the item object and calling its classes. We then want to make sure that we are tracking the depth of our menu. The depth of a menu is going to be the depth within the nested submenus. This is how we control whether an item is a top-level parent item or its submenu.

We then want to check if this item has a submenu associated with it. How we want to do that is we’re going to look at the array of classes that WordPress provides for this menu item. If the class “menu item has children” is present, then this is going to have a submenu. If it’s not present, then it’s simply a link located in the navigation menu. If this is a link, we then want to make sure that this item that is being linked is not the current page that we are on.

We’re going to check again using the item classes provided from WordPress and see if the class “current menu item” is present. If it is, we want a special tag called the aria-current=”page” attribute. We will place that into the link itself. That is going to denote that the current page that’s being viewed is the link that’s present in the navigation. If we are not currently viewing the page that this link is representing, then we can go ahead and output it safely as a plain link using the URL that was provided to the WordPress menu item.

Now, all of that is for a top-level link that does not have a submenu. If we are actually looking at a menu item with a submenu, we will want to output that as a button. We control our output for that item as a button with a class and an aria-haspopup=”true.” This will indicate that this button will toggle a mega menu underneath it. Then we want to add the aria-expanded=”false.” This will tell the page that, although this is a button that can trigger a mega menu, the current mega menu is not expanded.

We then output the item’s title, which, again, we can pull from the item object from WordPress. Then we want to close our semantic tag, whether it was a link for a top-level item with no submenu or whether it was a button, which would be a top-level item with a submenu. Again, this is a high-level, more conceptual overview of how walkers work. We will be posting the code for this so that you can follow along and walk through it yourself at your own pace.

That gives our menu an accessible HTML structure from the ground up. This is always going to be the best-case scenario because you’re able to control the structure without relying on front-end modifications. However, if you’re using a third-party plugin, it is very highly unlikely you will have access to that HTML structure. Here are some common modifications we recommend implementing through JavaScript.

The first is to ensure that all buttons are using semantic HTML. Frequently, we come across plugins that use span elements instead of buttons for mobile menu toggles and for top-level navigation items with submenus. Converting these elements to buttons provides more context for assistive technology, as well as allowing us to implement appropriate ARIA attributes. This next code example is a custom convert element function built in jQuery.

This function will be taking an HTML element, storing all of its attributes and data, replacing it with a different type of HTML element, and then reapplying those stored attributes and data. This is something that we do frequently when modifying plugins to convert those span tags into true HTML button elements to improve the context for assistive technology. Again, this code example will be available following the presentation.

Now, our next common modification is to implement the arrow key functionality. This enhances keyboard navigation by allowing users to use left and right arrows for moving horizontally between top-level menu items and using up and down arrows to navigate through submenu items. This modification is part of a larger modification and customization we did for a menu to allow arrow key functionality.

This is just the right arrow key, but let’s walk through it so that you can understand some of those concepts. Again, this code will also be available, so you can actually walk through it at a more detailed level. To begin, we’re going to start by using a switch case to listen for the arrow key that’s being pressed. In this case, we’re looking at, specifically, the arrow right key. We want to prevent the default behavior because the default behavior may vary widely depending on the plugin.

In our case, the right arrow key was not navigating anywhere, so we want to prevent that default behavior so we can start fresh and build our own behavior for the arrow key. We check to see first if this particular menu item contains a button. If it does contain a button, is the current mega menu beneath it expanded? If it is, we want to toggle that mega menu closed because we’re going to be moving focus to a next-sibling, top-level item.

Now, if this does not have an expanded submenu, then we’re good to just move our focus to the next item in the menu. However, if it is part of a current mega menu, we want to close that mega menu and return the focus where it should be to the next menu item on that top level. Finally, we also want to look at the open menu button. This is going to be the currently open menu. Perhaps, it’s not currently where we’re navigating, but a menu is open. We want to be able to close that using the toggle menu function so that that menu collapses before we move focus. This prevents users from being trapped in an infinite loop trying to navigate between left and right arrow keys.

Finally, we want to look for the next element in the list. This will tell us if the current menu item on that top level is the last item in the menu. If it is, we want to loop back to the start of the menu so that users can navigate with left and right arrow keys and loop endlessly through the top-level items. The same can be done for up and down arrow keys when in a submenu so that once a user reaches the end of a submenu, pressing the down key will loop them back to the start of the submenu.

These follow patterns in place by the Blind Institute of Technology for best practice when keyboard navigating through a mega menu. Again, this is a very high-level overview, but we will be providing the full code following this presentation. The final modification that we’re going to cover, I know this has been a lot of code. We want to prevent the Escape key from collapsing all menus on a page. Instead, we reprogram it to close only the currently open submenu and return the focus back to the parent button.

This is one final modification that is, again, more complex than what we can show here, but let’s walk through the example at a high level for an overview of the steps required to modify that Escape key behavior. We open again with a switch case looking for the key that is being pressed. If the case is an Escape key, then we want to set the target button to the current menu’s parent. Now, if this is a mobile menu, we want to especially see if it’s open. If it is, then we know that the target button is going to be that mobile toggle that opens and closes the mobile menu.

Then if this item is not the mobile menu button, then it’s very likely that it’s going to have a mega menu button class as a mega menu parent. Now, if this mega menu parent is currently expanded, then we want the target button to be that parent item. However, if the mega menu is not expanded but it’s still a mega menu class, then it’s likely this itself is a nested mega menu because WordPress allows pretty much an infinite amount of nested mega menus.

That can get highly complex. That’s why we want to check and see, is our current mega menu within its own mega menu item? Finally, we want to check and see if the current list is expanded. If it is on the target button, then we want to toggle that target button to close the list before we are able to move the focus. Again, this is a high-level concept. We will be providing the code so it’s easier to see it in action.

That was a lot to talk through. Pretty much, we just want to ensure that all buttons are using semantic HTML. We want to make sure that the arrow key functionality is present for navigating horizontally through top-level items and vertically through submenu items. We want to prevent the Escape key from collapsing all menus, and then we want to return that focus back to the parent item. These are just a few of several common modifications we’ve done to improve and enhance accessibility, but remember that it’s always better when you can to incorporate those accessible structures through the HTML using Nav Walker classes.

>> JENNIFER: Okay, so hopefully, people can hear me better. Let’s say you’ve updated your site. You’ve gone through some of these steps with automated testing, keyboard testing, manual reviews. You’ve made the edits that Eli has so lovingly shared with us. Those changes were great. You’ve reached out for the support on the issues you couldn’t address. One question still remains. What do I do now? Am I compliant or not?

One of the next steps that you want to do is to make sure you include real users to test that site. If you’ve noticed, there was no screen reader testing involved in our session today. That’s because only true users who use assistive technology as an extension of themselves should ever be performing those types of reviews. Experience is absolutely necessary, so that’s actually why we partner with BIT. That’s the Blind Institute of Technology.

BIT is a nonprofit organization with a mission of placing people with disabilities in the workforce and equalizing the playing field for everybody through technology. We’re working together to bring awareness and education to everybody we can in the digital space. They also help us perform our user testing for ADA compliance and have been really, honestly, experts in enhancing everything when it comes to accessibility at our practice here at Aten. It’s really important to note, though, that you really need to hold off on user testing and review before, unless you know your sites, they can actually use it, right?

The last thing you want to do is hand over a site that doesn’t work for assistive tech users, so that’s that keyboard portion at minimum. You aren’t going to get the feedback you want. It’s going to be really frustrating for those users to test and interact with your site. I always recommend, after you’ve implemented all the changes you can, after you’ve gotten support, ensure your site works at least with keyboard before you bring in any actual user testing. I think that’s it. I think we did it.

>> AMBER: Great, thank you so much. Thank you, Eli. I don’t know if you saw, but there was a comment in the chat that there was a lot of really helpful code. The other Amber has said that it is absolutely fantastic, so thank you so much. It looks like a lot of people appreciated it. It’s great to see how you took a WordPress plugin, and then what code you added to modify it, which is a really good real-world example for us. Why don’t we stop sharing, I think, for now? I have two questions. Anyone else, if you have any questions that you want to add into the Q&A, we would be happy to address them. Rochelle had asked, “What plugin are you using on that Oxnard menu, the one that you modified?”

>> ELI: That was actually the Max Mega Menu, I believe.

>> AMBER: As a follow-up on that, is that the one that you would typically recommend as a good starting point? Obviously, knowing it needs modification, but they all do. Is it better than some of the other mega menu plugins that you’ve seen out there?

>> ELI: Yes, that’s why we chose it for that project. It is one of the most accessible mega menu plugins. It does have a good usage of ARIA, especially in the mobile menu functionality. There’s really never going to probably be a one-size-fits-all answer for which mega menu plugin is the best, but I do believe that that one did get very close.

>> AMBER: I think this follows up on Marcus’s comment/question, which said, “Even solutions like Mega Menu Pro require so much customization.” I’m curious, have you ever built your own mega menu versus using a plugin that’s out there? If so, how did you approach that?

>> ELI: Yes, the answer is absolutely yes. That’s what we are currently in the process of using and testing out on some of our development environments is a custom mega menu that’s going to be mostly just walking through the elements, very basic level using the Nav Walker. The example I actually showed is the example from a plugin that I wrote for an accessible mega menu. We basically try to keep that as stripped down and simple as possible because, from project to project, needs will change, but accessibility is important in every project. We work with our own internal plugin. We are hoping someday to be able to release some of those snippets to the wild so other people can easily build too.

>> AMBER: Yes, it’d be great if you had a plugin that you could put out there, whether it’s on your GitHub or something you sell or something like that as an alternative. Amber asked if you have any experience with Elementor’s mega menu.

>> ELI: I do. I have worked with Elementor’s mega menu before. I’ve also worked with Divi’s mega menu as well. Elementor does a pretty good job as well. Out of the box, it does have good usage of ARIA. I’m not 100%, but I believe they actually use buttons for all of their mega menu parent items. Those are good signs to look for when you’re reviewing code from a plugin. Look for things like that. Look for those buttons. Look for the output HTML to see if it looks close. I believe Elementor still did require the keyboard navigation modifications for sure, and I believe also the Escape key, but it did get pretty close.

>> AMBER: Yes, I actually did some– Oh, go ahead.

>> JENNIFER: I just wanted to add one thing. If you’re testing out plugins and you don’t know maybe looking at the code, I’d recommend installing it and throwing some link content in there and just manually testing it too if you don’t know what you’re looking for code-wise per se.

>> AMBER: What I can say on the Elementor menu was I actually did some testing for them as well as David, who is here in the chat. I know he might have some videos on his YouTube channel about Elementor’s mega menu. David, feel free if you have one that is useful for Elementor users to throw a link to that in the chat. I know they put a lot of work into the mega menu. Alex Stein looked at it a little bit, who is a blind developer. I think it’s pretty good.

It is definitely better than the legacy Elementor menu widget, so I always recommend if you have an Elementor website to– Even if you don’t need mega menu capabilities, you should still just build your simple menu with the mega menu widget because it’s better than the other one. David had asked because you mentioned Divi and I’m always curious about this because I’m down on Divi. I’ll just say it. [chuckles] I did a thumbs-down right there because I don’t think they’re super great. What’s your opinions on Divi’s mega menu?

>> ELI: My opinions are similar to yours. [chuckles] Divi does a decent job with their mega menu, but it does require much more modification. It’s been a while since I used a Divi mega menu. The last time that I did, I believe I ended up eventually just using my own custom menu walker because I was unable to have that level of control. It was becoming too reliant on JavaScript. I knew that then all of the modifications could be lost if someone disabled JavaScript. I ended up building my own from a custom Nav Walker. Divi’s mega menu is not that great in my humble opinion.

>> AMBER: Paula, I don’t know if you could grab the link to Renee’s talk because I think it might be useful to include as a reference for David or anyone else who’s interested in Divi because she gave a whole talk on fixing Divi and tested out all the different Divi accessibility plugins. That is definitely a good talk for people to look at. Thomas asked a question, which I think is interesting, because I think what you were talking about was making fixes for one specific plugin or one specific website. Thomas was asking, “Is there a way that you can release these fixes and publish them somewhere so that we don’t have to fix every plugin individually?” Is there a way to do that and make it universal?

>> JENNIFER: Do you mean like a generic? Is that the question? A generic level?

>> AMBER: Well, this is weird because this gets a little bit into overlay technology, right? This is what an accessibility overlay tries to do. As we saw with the FTC finding accessibility a million dollars for lying, is it possible? Do we think it’s possible to universally just go out, see it’s a menu, and try to fix everything? Does it really have to be targeted to a specific mega menu plugin that’s in use?

>> JENNIFER: I don’t think you’re able to fix things at a high level. I’ve worked on a lot of menus over a long period of time and it would be great. First off, if those things existed, they probably would already be useful is one of the things. Every menu is so unique. Even menus that Eli has fixed or we’ve worked on, the plugin updates and then, all of a sudden, everything breaks. Even if you do your best to make a generic level, something that’s going to address like, “Oh, is it a span? Convert it to a button.” You may not be converting things that are actually intended to be that way. I don’t think that there’s going to be something that’s at a high level going to fix everything generically, successfully anyways.

>> ELI: I actually could tag a little bit onto that because it’s absolutely correct. The way I tend to approach these things is I have, in a repository, just a few modifications that I frequently make. That way, I at least have them for a quick access. When I’m working with a new menu, I can quick access my standard “fix kit,” so to speak. I used air quotes there.

I can use my kit to just make a few modifications to maybe the target classes or perhaps to the elements themselves that I am converting into to make sure that I can adjust it to a different plugin. That’s always a good option. It’s kind of the best we have right now is just to have a general repository of frequent changes that you commonly make to menus and then try to tailor them to each project if that makes sense. [chuckles]

>> JENNIFER: If I have a second, I want to expand on that. If you make fixes and they have a GitHub, you can always open a PR and encourage like, “We can’t make every plugin creator pull these things in,” but we can encourage them and be like, “Hey, we’ve done that before where we’ve opened a PR or a pull request and said, ‘Hey, we’ve made these fixes for you. Could you please pull these in? It would make it more accessible.'” Most of the time, it works. Sometimes it doesn’t.

>> AMBER: That’s what I would always advocate for, either a PR or, at the very least, an issue or a support forum post because in theory then it fixes it for everyone who uses that plugin and anytime you want to use it again.

The other thing could be, and I would say identify what your starter kit is, whatever that is for you and your agency. If you have a starter theme that you then make child themes off of or that you use as a boiler plate and then you iterate on for each client, but it all starts from the same thing and a starter plugin set. Because I think where accessibility can get really expensive and time consuming is if your components change every project and that’s the downside.

Sometimes we think, “Oh, it’s faster to just go buy a new theme that matches what the client wants and then build it out,” but then you’re starting from scratch every time because it might use different plugins. If you’re like, “No, these are the plugins I use. This is the theme that I use and base off of, it’s going to get a lot faster and then you maybe only have to fix it one time and then you never have to fix it because those fixes are always rolled into whatever you start with every time you have a new website. That would be my recommendation.

Melissa asked, you mentioned users turning off JavaScript in some cases, yet we need to use JavaScript to make our menus accessible. Is it correct to say our websites remain legally compliant and we’re going to say none of us are attorneys, right? We’re not giving any legal advice, but [chuckles] if they work with JavaScript, yet the user turns off JavaScript. How do you embrace that or what’s your thoughts on that?

>> JENNIFER: The best thing you can do, first case, is making sure that it’s got the right semantic elements. You’re going to have to check with a lawyer. I’ll be totally honest with you. I don’t know the ins and outs and I can certainly say Eli doesn’t either around where the legality falls for users that disable JavaScript. They’re probably using a different assistive tech to begin with if they’re turning that functionality off. But in terms of what accessibility statements and what the legal is around that, I couldn’t answer that, I’m sorry.

>> AMBER: The thing I would note is I’m not 100% certain that if all JavaScript is blocked that you would be able to have even maybe a fully functional menu. Unless you also block CSS at the same time, then all the links would be there. Because JavaScript is frequently used to change values. Certainly, your ARIA expanded would never switch from false to true unless you had JavaScript active. I don’t know, it’s hard. I know they say that it should work even without JavaScript, but I’m not actually certain that’s possible when it comes to a menu. As a developer, Eli, if you have thoughts on that.

>> ELI: I’m with you. I don’t feel that mega menus in the landscape of tech currently would be very functional without JavaScript, but I do know that different assistive technology can handle those elements differently. That’s pretty much why my go-to is always change the structure. Use a custom navigation walker if you can because then at least the structure is going to be solid.

If anyone turns off JavaScript, it’s not going to impact the structure as a whole. Because even when we do custom navigation walkers, we still do use JavaScript for the animation effects or the dropdowns, but it’s more so stylistic and not functional JavaScript.

I think that’s where the delineation lies for me is does it need it to work? In the current landscape, most mega menus do need JavaScript to function properly at some level. I guess that’s part of a broader conversation, but yes.

>> AMBER: In the chat, Craig says, I note that over the years of tech support with blind patrons, many choose to turn off JavaScript as a matter of course because of prior experience. Maybe because they’ve had a bad experience with JavaScript breaking things for them. David said he believes the Indian docs menu works without JavaScript on desktop but doesn’t totally remember. Perhaps worth exploring if you go to the Mozilla developer docs and see if you turn your JavaScript off, does it still function as an example?

But I think you’re right. Because what happens if you were fixing it all with JavaScript and turning the spans and the button JavaScript off, now they’re all just spans. Really, as much as you could fix the underlying, not with JavaScript but actually in the HTML or the PHP that’s outputting the HTML, that would be best.

>> ELI: Exactly.

>> AMBER: Evan asked about Astra’s themes menu. So I don’t know if either of you have worked with Astra’s theme menu before. Evan says it seems pretty accessible but it does not have arrow key functionality. Would you add that with JavaScript or search for an alternative solution?

>> JENNIFER: I haven’t worked with Astra. I don’t know, Eli, if you have.

>> ELI: I have not built a mega menu with Astra. I’ve done some theme work with Astra before but not a mega menu. I’m not sure what their level is of accessibility. Again, if it doesn’t have that arrow key functionality, it’s probably a good idea to implement it using JavaScript. If the menu is already well-established in your theme, it’s something that is already present. Again, some of these plugins also have a monetary cost associated with them. If it’s something that you’ve already sunk a large amount of money into and you don’t really see it changing away to a custom menu in the future, then JavaScript is pretty much the best you can do to modify those behaviors.

>> AMBER: I think that’s a great answer on that one. Kevin asked, when you add your own customizations to a plugin or to WordPress core, do you have issues when new versions are released? They have done some similar modifications to WordPress core blocks but recent changes to WordPress have broken their code. Eli, you want to take that away? We have thoughts.

[chuckling]

>> AMBER: Oh, I want to hear them. I think we all do.

>> ELI: All the time. It just happened with a project last week. Yes, there is always that risk when you update something that everything that you have modified will break. It’s happened with our JavaScript on that Oxnard mega menu. It has happened with extending WordPress core blocks. Pretty much the best that I can recommend is a development workflow that accounts for those updates possibly breaking things.

I go into every core update and every plugin update with the assumption that it’s probably going to break the customizations we’ve made to it so I very thoroughly test that on a development site. Generally, it does break at least one or two elements of the arrow key functionality specifically is one that gets overwritten many times. They change some of the element class names so it’s hard to reassociate those targets. Checking change logs when you have updates will sometimes show the code that changes or they will list any classes or structural changes to the output. Also, just being very thorough with your testing on a development environment before pushing updates to production.

>> AMBER: You mean you don’t just hit that update, select all update right on your live website?

>> ELI: Oh, I’ve done that way too many times. I know better now. [chuckles]

>> AMBER: I’ll say we internally have really shied away. It’s why we started moving towards a lot more custom versus using plugin like block libraries. We don’t use block libraries anymore because we got burnt by block libraries. It’s like core blocks or our blocks that we control and nothing else.

>> ELI: Exactly. That’s pretty much our approach, isn’t it, Jennifer? It’s core blocks or our own custom ones that we know won’t break. [chuckles]

>> JENNIFER: Too many times that has been an issue.

>> AMBER: That is an unfortunate thing when you’re– You know, it’s hard. The plugin libraries have a really great place because they give a lot of control to non-technical users. I think at some level, a website hits a certain threshold in user base or revenue [chuckles] generation or something where you start to realize it’s better to just have more control in house for someone else somewhere that is making plans and updates that knows nothing about your website.

Thomas said, if you all made a menu that was accessible, I would get T-shirts and bumper stickers printed to get others to use it. That’s your motivation there to try and build and release your plugin.

>> JENNIFER: I know this is WordPress, but if you are in the Drupal space, there is a menu that I’ve worked on and released that is accessible, that supports keyboards, but it’s only for Drupal right now.

>> AMBER: Do you have a link to that that you could throw in the chat? Because we do frequently have overlap with Drupal, especially like in higher end space, there’s a lot where there’s Drupal and WordPress websites. There may be folks that’d be interested in that.

>> JENNIFER: It’s inside a theme, so you’d have to pull it out, but you can take a look at it at any time.

>> AMBER: That’d be great if you don’t mind putting that link in the chat.

>> JENNIFER: I just put it in the chat.

>> AMBER: Thomas’s other question was, how do you feel about navigation menus that are not ARIA menu menus? This is a good question. How do you feel about the ARIA role of menu being applied on a website? [crosstalk]

>> JENNIFER: Oh, and actually using the role itself?

>> AMBER: Yes.

>> JENNIFER: That’s a really good question. We kind of take the mentality, it really depends on if it’s coming in a plugin already too. Because sometimes you’ll get a plugin that goes ARIA ham, which is actually really not helpful. I don’t know that I have any other questions. Any particular thoughts on the role itself, Eli?

>> ELI: I agree that it more depends on if it’s something you’re writing from the ground up or if you’re using a plugin and you’re modifying. Sometimes you don’t have access to change like ARIA role attributes, but a good practice that our accessibility specialist likes to say a lot is you want to use the structural semantic elements as much as you can.

Having a nav element, and then if you add the ARIA menu role to that, it’s covering every base, but having just the ARIA role, it’s a little bit more of a touchy area where it depends on, do you have access to that? Are you able to modify it into something that also has more context? Or is it just being applied to an element as ad hoc? Which is something that we see a lot with less well-supported accessibility or accessible menu plugins. They tend to just throw roles in ARIA on things without much organization, we’ll say. That’s where that rule comes back into place where no ARIA is going to be better than bad ARIA because bad ARIA is a horrible experience for everyone. [chuckles]

That’s my opinion on it, but I’m not well-versed enough to know specifically if it’s truly negative to write that role.

>> AMBER: I actually have some thoughts on this because it came up a lot with that Elementor mega menu. When they first released their mega menu version, they had actually made it have a menu role. One of the expectations with a menu role is that the tab functionality does not move between items, it’s only arrow keys. We had a lot of conversations with them about that, me and some other folks in the community, and they ended up reversing and going back. Because the thing is, is that ARIA spec for menus is really intended for application menus like a web app or like a desktop application, not really for website navigation menus.

The thing is, is that while a keyboard or screen reader user would hear, “Oh, this has a menu,” and then they’d know I can use this arrow keys to navigate. A keyboard only user won’t hear the ARIA, and so they would hit tab, go to the first item and then hit tab and it skips everything else in the menu and they think it’s broken. Because the idea is, you want to do what is expected on the web and normally you can tab every item in the navigation. Adding arrow key support is great but removing tab [chuclkes] key support is not. I would generally say, I would advise not to use the menu spec on a navigation menu on a website because I don’t think it’s the expected user interaction. That’s how I would do that.

I think that was the last question from the community. I do have one question which you didn’t talk too much about. I’m really curious on y’all’s opinions on mega menus that include nonpage links content. This is really common in some of those mega menu plugins where they show you, “Oh look, there’s a carousel inside [chuckles] this one. This dropdown has a Google map and this dropdown has three blog posts with the featured image and the title and the date and the read more link.” What is your opinion on building mega menus that include content other than navigational links?

>> JENNIFER: I have big thoughts on this. I want to skip link. If you’re going to put a bunch of mega menu content that has embeds or things like that, if I’m in a menu and I know that that’s what’s coming up, I just want to skip to be able to skip past it. Unless you lose– Sometimes on my phone, I have the Android’s accessible thing turned on so I can swipe through and it’ll read the text or make it so that I can choose to go into it and if I don’t want to, because it’s not the menu, the navigation piece, I just don’t want to interact with it. But that’s just me.

>> ELI: I actually agree with that. I think having the option to interact with it is one thing, but then being forced to interact with it can be a really negative experience. I think having the navigation be accessible and then if you wanted to add other embeds and pretty much other entire miniature content previews and things into your mega menu, just be sure you’re providing that skip link. [chuckles]

>> AMBER: I definitely on this, I think what is the purpose of a navigation menu? That’s what I go back to. A navigation menu helps people move around your website. I don’t think carousels or — Put your Google map on your contact page or your store locator page or whatever it is. It doesn’t have to be tiny in your navigation menu dropdown.

>> ELI: You can link to the contact page. [chuckles]

>> AMBER: Yes. We’ve built our own with advanced custom fields, mega menu builders, because we didn’t think any of the existing mega menus were good. Also, because we wanted to allow people to build mega menus but not insert random stuff, which all the plugins allow [chuckles] them to do, and so we’ll use ACF fields that do that to build one out. Those drive me bananas on websites and I don’t think they’re user-friendly and I don’t think they achieve the goal of a navigation menu. It’s hard because I think sometimes clients see them and they’re like, “Oh, I can get as much stuff [chuckles] in front of people.”

Craig says, stop trying to create the Mona Lisa with your website. Just make it function as expected. That may be a whole Twitter conversation about design versus art that people can go look at for that. Lily said, isn’t it better to choose for secondary navigation in lieu of very deep levels? I think that might also be a thing, really thinking about how much you’re nesting sub-items.

>> JENNIFER: I think I would always make a secondary nav if you’re going more than three levels deep because it’s really frustrating as a user to remember where you are when you’ve gone so [chuckles] many levels in and then good luck making sure on your way out.

>> AMBER: I do think this is where mega menus where there are columns can be really useful. A dropdown, that’s the second level at the top of the column, and then the third level is the items in the column. Then there’s not multiple flyouts. I think that’s nice, but I don’t like multiple flyouts, really.

>> ELI: I’m fully on board with just having the information presented clearly without looking for a flyout, especially using WordPress core blocks, the flyouts, I never know which direction they’re going to go. That’s a very confusing experience as a user. The fewer fl out levels, the better.

>> AMBER: For sure. This has been a phenomenal presentation and conversation afterwards. Thank you, Jennifer and Eli. Can you please tell us where people can follow up with you if they have additional questions?

>> JENNIFER: I think our contact information is on the Aten website. That’s aten.io and then the slash about should have both Eli and myself in the list. You can also get me at LinkedIn. I think it’s jldust. I don’t know, Eli, where you’re at.

>> ELI: I think mine’s efrigoly, I believe, but–

>> AMBER: On LinkedIn also?

>> ELI: On LinkedIn also, yes.

>> AMBER: Great. Thank you, both, so much. I’m going to wait just a minute to let the captions catch up with us. In about two weeks, we will have the recap up with all of the links to the code and the presentation for anyone who wants to review it. Thank you, everyone, for attending.

>> [01:18:55] [END OF AUDIO]