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