> The main menu? Which is behind the same ≡ button on most pages on the internet?

This triple dash thingy (≡) is in this case "identical to" Unicode character, so this is what you'd most probably hear from the screen reader. Other pages (mis)use similar characters, for example "Trigram for heaven". Not very helpful.

Truly accessible active elements must communicate their function through meaningful text, not cryptic astral Unicode from exotic blocks.

To be fair the OP hides the trigram from screen readers and provides them with the ‘open menu’ label.

No, they did not, they present both "accessible hidden link" and "inaccessible visible label", at least I see no `aria-hidden="true"` in the code [1] on the label right now, I see just:

    <label for="menustate">
      <span class="open">≡</span>
      <span class="close">×</span>
    </label>

(Fact that wording of the link in the article pointing to the codepen is "this codepen" is also … not right.)

[1] https://codepen.io/enyo/pen/yLqjrOR

You're right - I guess I assumed they'd added that in the full codepen.

Oh you’re right, I forgot to add this in the article + codepen. (It’s how the button on the site itself is implemented and I forgot to integrate it)

The use of this symbol in the article is a placeholder. Obviously nobody would actually use this on their website...

Offering a show menu button to screenreader users is accessible but poorly usable. They can’t see the menu. ‘Showing’ and ‘hiding’ mean nothing to them.

And for your keyboard navigators using the visual interface, perhaps this hints that you could afford them a similar opportunity - where, from being focused on the menu, they could either descend into the menu, expanding it, or skip the menu and move focus to the next control. That’s how most OS/application keyboard accessible menus work - they don’t have ‘expand’ and ‘collapse’ affordances at all.

Mh.. yes I agree. "Expand menu" and “Collapse menu" is probably a better wording.

It's an interesting distinction for sure. Perhaps "Activate menu" and "Deactivate menu" would work too, particularly as there's no reference to visual things - what would "expanding" on the screen mean in the context of a blind user?

Not all screen reader users are blind though. There are plenty of people with enough vision to see the screen, but cannot easily read the text on the screen. And on mobile where users interact with the screen reader via the touch screen, expand/collapse or show/hide fit the bill perfectly.

blind folks aren't dumb. they can analogize what 'show' and 'hide' mean in context (not to say that this shouldn't be made better).

in any case, i agree that there's a lot going on to add affordances for keyboard users that screenreader users don't need. screenreaders would just need the <nav> element (probably should be aria-labeled too) and the <ul> link list.

it's neat but a little convoluted. i'd also vote for using a <button> rather than a checkbox plus anchors, but buttons do have technical limitations (as noted elsewhere) that browser engines should fix (similar to how dialog elements are now nearly javascript-less, only requiring a `showModal()` call to open), rather than having to have authors work around them.

The 'main' menu? Implying, there are other menus.

So is the ≡ the main navigation menu?

The account options menu?

The preferences menu?

The menu of the application platform that's wrapping the page you're on, rather than the page itself?

The menu showing all the sister companies of the site you're on?