[jameshart]

Proof that accessibility and usability are entirely orthogonal.

For screen reader users only, this provides them with the information that activating this link will open or close a menu.

Screen reader users do not need to open or close menus. Menus do not take up space or sit in front of other content. Closing a menu offers no usability benefit to a screen reader user.

All they need is the options to be present under a navigable heading that they can skip to when they need to access those options.

Meanwhile, non screen reader users are forced to guess what will be behind the ≡ button this time.

[enyo]

> Screen reader users do not need to open or close menus.

Agreed, but you don’t want keyboard accessible menu items available for users that aren’t visually impaired. Offering a “show menu” button to screen readers is not less accessible to them than skipping the navigation section.

If you’re building a page that is only meant to be used by screen readers, then you are absolutely right.

> Meanwhile, non screen reader users are forced to guess what will be behind the ≡ button this time.

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

[jameshart]

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.

[clairity]

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.

[enyo]

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

[frereubu]

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?

[frosted-flakes]

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.

[myfonj]

> 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.

[enyo]

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

[jameshart]

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

[myfonj]

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>

So there still remains "readable" structure loosely identical to

    <label>identical to multiplication sign</label>

(With active CSS, only one half would be presented to SR, since the other has `display: none`, but still…)

BTW 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

[enyo]

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)

[jameshart]

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

[jameshart]

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?

[runarberg]

> Screen reader users do not need to open or close menus.

Are you sure about that? I’m not an expert but I was under the impression that many screen reader users use the screen reader (among other tools) to interact with the visual representation of the user interface. Not all screen reader users are 100% blind (or at least that’s what I’ve been told), and actually use a variety of zooming, high contrast, magnifying glass, etc. and a screen reader.

If my impression is correct, then many screen reader user indeed open or close menus, and they are in the way (especially when zoom levels are pumped way up), and visually hiding them by default does offer a ton of usability benefits.