Minor a11y improvements (suggestion).

they do hide drop menu content while the user cycles through all the anchors

Which is what is needed for sighted keyboard navigators (who, incidentally, far outnumber the visually impaired users).

You misunderstand. I’m not suggesting that the menus be permanently visible, if that’s what you’re thinking. Try the demonstration I linked to. It works like a “normal” drop menu except that it will also call links on focus, not just on hover.

If using “standard” drop menus, like the ones on this site, you cannot see the drop menu content at all if you are using keyboard navigation. It is inaccessible (visually) even if your eyesight is perfect. I think we could agree that this is not exactly what is needed.

Try it here. The links to Plugins, Themes and Mobile under the Extend tab cannot be seen if you are using keyboard navigation. The only way you could get to those pages would be to take a wild guess and click to see what happens, which is not the ideal way to navigate a site you may be unfamiliar with.

Sure, you want the menus hidden when you are not using them, but you do want to be able to see the link that is currently in focus. It’s like to wanting the drop menus to open on hover if using a mouse. You want to be able to see the content.

I’m not suggesting that the menus be permanently visible, if that’s what you’re thinking.

No I wasn’t. Even hidden menus can create barriers for keyboard users if they are forced to tab through them. Unlike screen reader users, sighted keyboard navigators do not have access to a Links List. The main Admin menu in 3.2.1 does not force that on keyboard users. Ditto the 3.3 admin menu.

I agree that the focus/active states could be improved and I’m already trying to put together some CSS fixes that could address these issues with a longer term view of bundling them into an Access plugin.

you cannot see the drop menu content at all if you are using keyboard navigation.

That is as it should be. and I’m speaking here as:

a) someone who has 11+ years of working with disabled users
and
b) someone who spent almost a year navigating (and coding) by keyboard & VR (and, boy, did I learn a lot!).

Keyboard users by & large do not want the dropdowns/flyouts to be available as that forces them to move through these underlying menus (unlike mouse users). Generally speaking, they want access to top level menu items only with an option to activate any one top-level link to disclose any sub-menu.

The only way you could get to those pages would be to take a wild guess and click blindly to see what happens

And that is how these users prefer to work because the alternative is horrendous.

Ok, I can see your point. It makes sense. So, if you want the drop menus to be optionally accessible then you’ll need a js-based solution rather than a pure css one. That makes sense for other reasons too (mouseout delay, for one).

So are you thinking of something similar to the vB system, with a click-to-open functionality? I’m interested in this discussion generally, not just specifically for WP.

Also, if this is going to be better for a11y then ultimately it should be default functionality rather than a plugin. Plugin is always a good start for new features, of course.

Why js? That causes issues for some AT users (and incidentally tends to drain cell phone/mobile devices pretty quickly to).

So how do you plan to get optionally-accessible drop menus without js?

Well, I’m not sure what you feel the issue is with the current menu system (active/focus CSS aside).

That didn’t answer my question. ??

I mean if you want to get optionally accessible drop menus without js that’s great, but offhand I cannot see how you could do that without using js.

Anyway the other thing, for mouse users, is the lack of mouseout delay. Having the menus close instantly if you go slightly off track is a real problem for some people. I’ve had them grumble at me quite a bit about it.

I cannot see how you could do that without using js

You can create pure CSS dropdown menus. If you want to add some js enhancements, fair enough – as long as it degrades gracefully without js.

Having the menus close instantly if you go slightly off track is a real problem for some people.

Is this generally or in relation to the 3.2 admin menu.

You can create pure CSS dropdown menus. If you want to add some js enhancements, fair enough – as long as it degrades gracefully without js.

Yes I know you can create pure css drop menus. I can code those easily and have done so many times. I also agree that it should function without js, given the possible reasons why it might have to.

However, you were talking about giving users the ability to choose whether or not to access a drop menu when using keyboard navigation. If you want to do that without js, then the drop menu content has to be in the tabindex, and if it’s in the tabindex then keyboard nav will cycle through it automatically.

The only ways I can see of preventing it doing this are to assign it to the tabindex if and only if the user chooses to access the drop menu, or by using a click to open system. That’s not something you can do just with css. You could do it with js, and you could do it with php, but not with css alone (unless I am missing something).

Is this generally or in relation to the 3.2 admin menu.

Generally. Applies to any platform that uses drop menus.