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.

It's really about discoverability

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:

"What navigation?"

The issue isn't that the button needs to be near or within the navigation to reveal it to the user. With JavaScript, a button could be located at the bottom of the DOM and still open a navigation at the top of the DOM. But only if it used React.js (this is a poorly executed joke. I am kidding. But I am also not removing it as I want to see how many people get unreasonably mad at me.)

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.

Hiding the <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 <ul> or <div>s surrounding multiple components of the navigation), the navigation never gets hidden from ATs 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 <a> element to allow for functionality without needing JavaScript) within the navigation allows for the navigation landmark to exist and to always have discoverable content within it (the button). The button then would be used to control the visual state of the navigation's contents...you know...the stuff you're hiding for "reasons" :), via JavaScript, CSS, and with appropriate aria hooks (look up aria-controls and 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.