Home » accessibility » In which WordPress 3.5 fixes menu accessibility. Sort of.

In which WordPress 3.5 fixes menu accessibility. Sort of.

If you’ve jumped on the wordPress bandwagon recently, you know they’ve unleashed version 3.5 on the masses. You probably also know the huge thing they’re jumping all over is the improvements they’ve made to their media library. That is not, however, the huge thing I’m jumping all over. Since about version 3.3, users who have visual impairments and who use a variety of screenreading technologies have had a bit of difficulty, without the use of additional plugins, with accessing the various submenus WordPress has to offer. This is because, in 3.3, they’ve moved to a form of javascript flyout menus that are designed only to appear when the top level menu is hovered over with the mouse. Useful, until you run into someone who can’t use the mouse. Enter yours truely, and a few folks he’s hosting. And enter this little used dialogue on the WordPress bugtracker.

I’ve kept an eye on it since 3.3, and it goes through phases where people will poke and prod at it, then leave it alone for a few months. Apparently, somebody poked and prodded at something else, or just didn’t nail the ticket with that prod, and now, things do what they’re supposed to. Well, mostly. On a clean install of WordPress, which I just so happened to bust out before upgrading this site, completely unmodified from the core platform, the menu links that gave me and others trouble in this ticket behave as expected. And hey look, the menus don’t play hide and seak until you do some fancy dancing with your screenreader of choice’s advanced features–a big plus, in my world. Bonus points for that, guys. So now, we switch to this site. Because if I’m gonna break a bunch of folks I’m hosting, I might as well break me first, yeah? Yeah. So I do. And guess what? Not quite perfect.

The dashboard menus still do what they’re supposed to–that is, be damn well good and visible when they damn well need to be good and visible, without the afore mentioned dancing. But the top level links still don’t read like they’re supposed to without help. A tiny bit annoying, but can still be worked around–with the same workaround I’m already using because of what they broke in version 3.3. If you weren’t aboard the WordPress wagon when I was playing with this, let me introduce you to my new favourite plugin.

OZH Admin Drop Down Menus is a plugin that forces your dashboard menus to stay visible, permanently. It has the side benefit, which is the only reason I’m still using it now, of giving the top level menu links a readable label. Since they improved that area of accessibility in 3.5, I wouldn’t suggest installing it on a new install–unless I just got lucky and it’s actually still largely broken. For on already running installs? Definitely continue to use this plugin. And if you need assistance making it more useable from an accessibility perspective, let me know and maybe we can work a little something out.

, , ,

2 responses to “In which WordPress 3.5 fixes menu accessibility. Sort of.”

  1. I haven’t done my upgrade just yet. This week has been pretty light on the Cometing. Good to know they haven’t totally fixed this yet. I’d rather find that out now than after I’ve done something drastic and unnecessary.

    • They didn’t break it worse, which was my biggest worry. I can work around this broken still. Thank god, as I’d really rather not have to code over that mess…

Have an opinion?

recent Posts

Recent Comments