It’s not really about the button…
This morning I woke up to another great piece of advice by @heydonworks:
At least, I considered it great advice. You sometimes you have to read between the lines with Heydon. Case in point, his excellent article Progressive Enhancement Makes Me Sad.
But I digress. He was being straight forward here.
What became apparent to me, in further expanding on this topic in a conversation with @SaraSoueidan, and seeing the tweet storm that our public thread had started, is that there were many who did not quite grasp the full significance of the example, and why placing the button inside the navigation was important.
Discoverability is key
What people were primarily focusing on was the button’s placement and how that would affect the design, the way they’d need to code the CSS to target the navigation’s
<ul> instead of the
<nav> itself, and why couldn’t they just put the button somewhere else if they used things like
aria-controls to point to the navigation?
To all of that I’d respond…
The issue is that correctly hiding a navigation by default, whether that be done with
display: none; or
visibility: hidden;, not only removes it visually from view, but also removes it from being discovered by assistive technologies (ATs), screen readers.
You see, users of ATs don’t just start feverishly tabbing through an interfaces just hoping to find what it is they’re looking for. Well. Maybe they would if they were trying to prove a point about how horrible a site was coded. But yeah. Not really.
Typically when an AT user comes to a page, they do what sighted users do, they do a quick scan of the page. Obviously their method of doing so is different. While sighted users can quickly just look around a page and determine functionality and relationships by appearance, a fundamental way for AT users to determine a site’s structure and significance is by landmark discovery. (There are other methods as well, but that’s a much longer article for another day.)
Looping back to the topic of the hidden navigation, this is where the problem arises and Heydon’s example is the solution.
<nav> removes it from the landmark listing. So AT users would come to the page and on initial review could only determine “Oh. This page doesn’t have a designated navigation. Well. This should be fun…”
It’s not that the navigation couldn’t or wouldn’t eventually be discovered. The issue is that there would be no easy access to it. A user would have to learn that the element to open the navigation was in such-and-such location. Remember that location. Navigate to and through that location. Open the navigation and then would they finally get to the page’s true navigation listing(s).
By placing the menu button within the navigation landmark, and instead hiding the rest of the navigation’s contents (whether that be the primary
<div>s surrounding multiple components of the navigation), the navigation never gets hidden from ATs</code> and its much easier to discover.
So what are the takeaways here?
Mainly, this is more about being mindful with how our documents are setup and what we reveal (or don’t) to all users with our document structure and CSS.
Including the button (I’d actually recommend it being a
aria-expanded to see how they could be used here).
The high level intent may be to visually hide a navigation from view, until a user specifically wants to interact with it. But the overall intent is likely not to obscure the fact that a navigation exists.
In the end we all want to make work with great user experiences. Let’s just make sure we’re being mindful of how how we construct our paths to get there, so that we don’t lose anyone along the way.