As I work on various projects, I keep circling around the idea of how best to implement a responsive navigation menu that just works for everyone. It’s been almost three years since I blogged about an accessible navigation menu, and I’m ready to revisit the topic.
Since that blog post, the responsive menu for the Genesis Sample theme has been drastically revised, but there are some pieces still missing, in my mind. The issues I want to see a great theme navigation menu solve are:
- honor skip links, no matter what child theme is used, and however many navigation menus the theme adds
- if a submenu is open, and then you open a different one, the first submenu closes
- combine multiple navigation menus into one, which makes mobile more manageable
- gracefully handle parent menu items which are not actually links on their own (usually the “link” is a
#) - behave consistently, regardless of screen size
The first two (1,2), I addressed in the last post on this topic, and they’ve been added into the Genesis Sample theme script and SuperSide Me (my own mobile menu plugin). The multiple navigation menus (3) into one is not in my last post, but is in Genesis Sample, and has always been part of SuperSide me. (4) has been addressed in SuperSide Me, but I don’t think anywhere else. And (5) has become my new golden ring to attempt to grab.
A Quick Note on Superfish
When the Genesis Framework added accessibility support, Superfish was the script of choice to make navigation menus accessible. However, we discovered that the best way to make an accessible mobile menu was to disable Superfish when the mobile menu is active. This has always been a bit of a puzzler for me, but it seemed the best way for it to work at the time.
You May Also Like:
The Differences Between Mobile and Desktop Menus
As things stand within Genesis–and not only within Genesis, but I’ve seen it in other themes as well, such as Twenty Seventeen–if a menu item has children, or a drop down menu, the difference between mobile and desktop behavior is pretty significant. Mainly, a submenu toggle button is added to the parent menu item. On mobile/small screens, clicking the button is how you open the dropdown/submenu. On desktop, or larger screens, those buttons are visually hidden. Some themes visually replace them with CSS, to show a submenu indicator; some themes do not.
I think that the visual indicator for a submenu should be in place regardless of screen size. The W3C recommendation is: “Indicate menu items with submenus visually and using markup.” So, let’s take that one as a given. It’s potentially a simple CSS issue. Twenty Seventeen adds the visual indicator as an SVG icon; this is another option.
My thought is that this isn’t a great way to do it, and it’s because of what I consider to be the more striking difference in behavior between mobile and desktop navigation, which is the behavior of how submenus are accessed, especially for users navigating with a keyboard. The relevant W3C comment:
Submenus should not open when using the tab key to navigate through the menu, as keyboard users would then have to step through all submenu items to get to the next top-level item.
Currently, the desktop menu behavior I’ve encountered doesn’t adhere to this, and, as far as I can tell, keyboard navigation users will have to go through every submenu item (and sub-submenu item) to get from one parent menu item to the next. We’ve solved this behavior on mobile. I’d like to solve it on desktop as well.
Re-Imagining Website Navigation Menus
I’d like to share with you what I’ve ended up doing. This post isn’t a tutorial so much, but a proposal with code. If you’d like to try it out for yourself, I’ve put all of my code together in a Github repository, as it’s easier to manage and update than a gist, and given instructions on the readme. Here’s the repository for the Leaven responsive navigation. The high points of what I’ve accomplished with this are:
- skip links are (still) honored
- only one submenu is open at a time
- on mobile, multiple navigation menus are combined
- parent menu items which are not links on their own are converted to submenu toggle buttons
- although they’re different visually, the mobile and desktop menu behavior is the same, or as close to it as possible
- if a mobile menu plugin is active, the theme mobile menu behavior can effectively and easily be disabled to reduce overhead/potential conflicts
So I’ve hit my five key criteria, and one more. The ones new to my approach are combining the menus on mobile (3): I’ve adapted the Genesis Sample approach there somewhat; parent menu items which aren’t links (4) are converted to toggle buttons, similar to how they’re handled in SuperSide Me (this ends up in a menu which flexibly uses both W3C recommended approaches to the parent menu item behavior); the mobile/desktop behavior is consistent across screen sizes (5); and I can check if a mobile menu plugin is running and refrain from doing mobile menu acrobatics if one is (6).
Wait, What About Superfish?
The key thing I had to do to make all this work was remove Superfish from the equation altogether. Since what I wanted to do, in essence, was to expand the mobile menu behavior to desktop, this made sense, and meant I was no longer fighting a script’s default behavior. In Genesis, this means not including drop-down-menu in the list of accessibility features to enable.
Because I’m not using Superfish, and I’ve already resolved the parent menu item issue for mobile, what I’ve done is just to use the mobile behavior at every screen size. Instead of creating submenu toggle buttons for mobile, and hiding them on desktop (and maybe replacing them with something else), I’m using the toggle buttons everywhere. A keyboard navigation user can now choose to open the submenu, or jump to the next parent menu item without having to go through all of the menu items. The hover behavior is visually the same, although I’ve added a distinct delay on closing submenus based on the W3C recommendation.
How to Try Out This New Responsive Navigation Script
If you’d like to try this out for yourself, please do! Just visit the Leaven responsive menu Github repository and clone or download it to your computer. It’s not a plugin on its own, as it’s meant to be integrated with your theme. Check the readme instructions for where to put the files and how to load them.
The script itself should not need to be edited, unless you find a bug, and both a regular and minified version are provided.
The CSS is completely rewritten from most Genesis child themes. It is mobile first, and separated into Sass files if you want them:
navigation.scss: general navigation styles (nav)navigation-genesis.scss: Genesis specific navigation stylesnavigation-buttons.scss: all toggle button stylesnavigation-no-js.scss: fallback styles if JavaScript is not enablednavigation-social.scss: social menu navigation styles (social icons, based on Jackie D’Elia’s tutorial using Twenty Seventeen’s social menu)navigation-search.scss: styling for adding a search input to a navigation menu (based on this tutorial from Sridhar Katakam)
In my own theme, I follow this with very minimal styling for each registered menu location (changing a navigation bar color, or text case, etc.). All other navigation styles are removed.
The sprites are from Font Awesome 5; you can use these or another, as you prefer.
The PHP files are broken into multiple files due to how my theme is set up, but you can add the functions to your theme however you prefer.
Final Thoughts
Is this the best way to approach website navigation? I am not sure, honestly. I do feel like it’s a better approach than what we’re currently using, which is a better approach than what we had before. So we keep working and iterating and improving. If you’d like to try this out for yourself, I would love any feedback, comments, and/or pull requests.
Photo by Bundo Kim
Hi Robin,
You seem to have thought about every aspect and it makes sense to me mostly. What you propose and demonstrate seem to implement the consensus of the W3C better than most menu’s I’ve seen so far, so that’s a plus anyways.
I’m not sure if mobile menu’s always need to work like desktop menu’s, since each platform might have their own common design-language and the differences in input devices (keyboard and mouse, versus tough) might lead to differences in that design and the approach of it. Offering visitors what they intuitively understand, or are used to will probably be best, because then they don’t have to think about the controls.
I recently saw a presentation in which the presenter asked if the design language of the mobile menu is part of that intuitive design language that visitors understand, and the looking glass that is commonly used for the search (but also for zoom), and he stated that both were not, and that the modern design of leaving out the button for search next to the search field also isn’t widely and intuitively understood, so users might not know they have to use the enter-key to go search.
If that is true, using the word menu next to the hamburger icon and using a search button with the actual word search on it to activate the search, might be better practice than what we tend to do from an esthetic standpoint. It can get confusing.
Looking at for instance the new Studiopress Essence Pro theme, I saw a search field implementation that was very confusing for me since the field had a looking glass icon but didn’t look like an text entry-field, just a label, and when I entered this text-field no visual change happened, so my cursor stood in a field with an transparent background and no border and no search button, just at the end of the word search (a placeholder)… and now what?
Without a visual indicator that told them they were even in a text-field, how would visitors know they even can start typing and the text search will disappear at that point and be replaced with what they are typing? Very confusing and such a search disappearing when the screen is smaller, made me wonder if the designer thought visitors on mobile phone’s wouldn’t look for stuff on a website.
Visual appealing, perhaps, but not well thought through in practical aspects. I choose the theme because it is very attractive in it’s presentation and has a lot of good stuff, but the header (menu’s, search option) could have been better designed in a practical sense. It will take some programming to get it right.
Of course I’m experienced enough to find my way in any case, but I wouldn’t want to do such a thing to the visitors that might get confused and don’t know why the looking glass doesn’t react when they click on it, since it’s just a visual label and not a button. Also they might not know they need to use the enter-key and get stuck or just get impatient and leave. Not what I want, and I have seen your website agrees.
Going back to the menu you propose, I have found I got confused at some point on your website. When I made the screen smaller and the header went to the bottom, that was really disorienting since I did’t anticipate such a move and for a while didn’t know what had happened. Even though I myself have wondered if the bottom would be a better place on mobiles too, since the controls on the mobile tend to be on the bottom and it makes single-hand usage faster and easier. The move makes sense to me, but how disorienting when you are so used to find such a header on top with a hamburger to the right and not as a footer of the viewport.
I guess we get used to stuff and probably, when using different websites, we tend to look where we expect stuff first and again and then some…, before finding it where it is. In this case it really took me some time to find it, what was really unexpected and strange to experience. Such a stuck habit already.
Last, about the point of combining menu’s, when there are more menu’s in the website… I might not want that always to happen (and again the newest Studiopress theme does it too, and not to my liking). I might want an entirely separate menu on mobiles, or might want the main menu to get a hamburger and the others to disappear, or I want one menu (a top-menu) to partly stick to the top and the main menu to become a hamburger. So what to do depends, in my view, on the design and the usage of the menu’s and should so be easily controllable by the admin and/or developer.
The websites I work on tend to have lots of integration (e-commerce, events, online courses and such) and want to have some options always visible on mobiles too (like a share-option, a cart icon with an indication that there is something in the cart and the menu-icon). So having some control over any mechanism that combines menu’s will be important.
Perhaps such controls might be nice to have in customizer or even in hooks, but they need to be there to make such a plugin of general use. Having said that, the solution of just separating mobile menu’s from desktop menu’s is strait forward and might give the maximum of control, so that is always an option.
There is just one use case in which I can imagine it makes implicit sense to do it and that is what happens in the Studiopress “Modern Studio Pro” theme. In that theme the main menu is split in two parts because of the design in which a logo is put between the two parts. Since for the visitor this will be perceived as only one main menu, it makes implicit sense to me to combine them in the mobile hamburger menu. There might me more use cases, but this one is clear to me.
In other cases I might opt to leave out one of menu’s or want to put one of them on a lower level in the main menu, instead of just sticking them together. The reason might simply be that I can have several menu’s with overlapping options in them and don’t want to duplicate options in the mobile menu.
So there is a lot of variation to cater for when having that functionality and it might be a lot simpler to use separate menu’s. However merging menu’s is always a better option than a design of making a hamburger for each separate menu (some themes do that), since that case will make no sense to a visitor.
So that were my two bits. Hope that it made some sense. Thanks for your thoughts on the subject and the sharing of your implementation.
Cheers,
Hans
Hey Hans, you raise good points!
I agree that it’s not always desirable to combine menus on mobile. For some sites where I’ve needed to do this, I’ve just modified the secondary menus array so that they’re not automatically combined, and then used CSS to force them to always show.
As far as my own site goes, I should have clarified that the mobile menu functionality here is handled by SuperSide Me instead of the theme script, and yes, I chose to move the menu buttons to the bottom of the screen because of my thumb. It’s just a setting in the plugin, though, and easy enough to change.
I think my primary concern in the difference in behavior between mobile and desktop menus is access to the submenus and their items, because to me it feels like a significant disparity (and current desktop implementation is contrary to W3C recommendations). You are right, I do not expect that we can attain complete parity between the different ways we interact with different screens, but my hope is that this brings us closer.