WordPress 3.5 Accessibility Update – November 2012

Published: Nov 19th, 2012 | Author: Graham Armfield | 10 Comments

Reading Time: 6 minutesBack in the summer of 2012 I presented to WordCamp UK on WordPress and Web Accessibility – including demonstrating some of the accessibility shortcomings within the WordPress admin screens. My presentation generated much more interest than I ever believed possible and, as a result of the presentation and the discussions afterwards, I (and others) raised a number of Trac tickets on the WordPress core to point up some of the key accessibility issues. Some other people with disabilities also added their comments.

But what has actually happened since then? And how much has actually changed, given the imminent release of WordPress 3.5 in December 2012?

This post talks in overview terms about some of the progress made on accessibility in WordPress since the summer. I’ve also included some specific comments about some of the changes that have been made – both good and not-so-good.

So which Trac tickets are we talking about?

Use this link to view a concise summary table of all accessibility related tickets on the WordPress trac system. They are shown in ticket order, and the first one raised as a consequence of my WordCamp presentation was ticket #21283 – indeed it was actually raised during my talk.

You’ll see that there have been a few more raised since then.

Some good news

What’s immediately obvious is that a substantial number of the accessibility tickets raised since ticket #21283 have been flagged for inclusion in release 3.5 and most of those have also been flagged as fixed. On the face of it that is really great news and shows a real desire amongst some of the WordPress development team to make WordPress more accessible.

I’ve been really busy on client work over the last few months and only now that the beta versions of WP3.5 are available have I had the opportunity to do some limited testing of what’s been done.

Initial impressions

Keyboard focus – visibility and tab order

The first key change to notice about the WordPress admin screens in the latest beta release is that a huge amount of work has been done to make sense of the keyboard tab order and the visibility of focus. Accessibility is never just about blind screen reader users but a meaningful tab order is certainly helpful for those users. That combined with clearly visible keyboard focus is a substantial help for those sighted users who rely on keyboard interaction to use websites.

The 3.5 interface is has been cleared up and all the apparently empty links present in 3.4.2 have gone. The admin submenus are once again included in the tab order by default – rather than hidden behind some obscure keystrokes. And focus is much more visible all round.

This is really good.

Skip links

The new skip links in WordPress 3.5

The first link one sees when tabbing from the top of the browser window is a brand new Skip to Content link using the pleasing blue colour for the button-type background. Following this link takes the user (not surprisingly) to the top of the main content area within each admin screen – thus saving no end of tabbing. This development was done in answer to ticket #21310.

The very next link is a Skip to the Toolbar link which avoids the rest of the main admin menu options.

The addition of these links is progress, but I am disappointed that my own (and others’) views that these links should be permanently visible was not taken forward.

Logging out

Another ticket that I raised (#21312) concerned the perceived lack of a way to logout of WordPress admin without using a mouse. Apparently it was possible but only with some obscure keystroke combination that was not documented anywhere.

However there now is a specific Logout link button that becomes visible when it gets keyboard focus. It’s located at the end of the admin toolbar – some xx keystrokes in from the top in an ‘out of the box’ WordPress install.

Once again, this is progress of sorts, but after attending another WordCamp UK session on WordPress security I still believe a permanently visible logout link should be an obvious addition – it’s such key functionality after all. What do you think?

Another problem of not having a permanently visible logout link is that it makes life harder for those using speech recognition software such as Dragon Naturally Speaking. In order to logout, these users are forced to perform some crazy dance controlling the mouse cursor in a ‘Golden Shot’ style.

There is still work being done on this one, but I can see that a plugin to add an overt logoff link to the main menu links might be needed here.

Theme Customizer

Theme Customizer panel – showing colour picker controls that are (in theory) keyboard operable.

When the Theme Customizer functionality was introduced in WordPress 3.4 it attracted a lot of attention as a way of allowing non-technical site owners to customise the themes they were using without diving into the code or stylesheets.

Whatever your view on the Theme Customizer functionality it wasn’t possible to escape the fact that it was designed and developed without giving a single thought to accessibility. Unfortunately it proved pretty much impossible to even access the Theme Customizer panel without the use of a mouse – let alone actually influencing any of the options within it. Fundamentally, keyboard focus was not transferred into the panel so anyone using a keyboard was stuffed – and couldn’t even easily find a way to close the panel.

Well the good news is that significant efforts have been made in this area (ticket #21283). The situation is still changing as I write this, but it is certainly possible now to tab into the panel and to interact with most of the settings with the use of a keyboard. Screen reader users are getting some good feedback about what’s going on – although things are still not perfect in this area.

I’ve also done some testing with Dragon Naturally Speaking but the results here are not so good. The Customizer panel can be opened but Dragon can’t seem to recognise any of the subheadings for the options within it. This is potentially because they are not actually links, but I’m not sure. Trying to close the panel also brings its surprises as Dragon has a tendency to think you want to close the whole browser window.

I’m still learning about Dragon Naturally Speaking myself so anyone who has more detailed knowledge may like to comment.

Custom menu functionality

Custom menu – showing dragging to set hierarchy

The custom menu functionality is a particular favourite of mine – and my clients who like the flexibility of creating their own WordPress menus. Unfortunately, fixing the accessibility issues here is the big one that appears to have got away.

The custom menu functionality as some of you may know relies on the use of a mouse to drag and drop elements on a screen to build up the menus, and the hierarchy within them. Obviously this functionality is hard and/or impossible for those with visual impairments, and it is a challenge to those who can see but who rely on keyboard interaction.

In raising ticket #21289 I was hoping that a keyboard accessible version of this functionality could be provided that worked in a similar way to the accessibility mode with Widgets – a user interface that also relies on drag and drop. Although few blind users know it’s there (see Screen Options later), the accessible Widgets functionality allows allocation of widgets to any of your sidebars just by use of the keyboard. It’s fiddly, but it does work.

Anyway, there has been no movement on this one – perhaps there was just too much in 3.5. I’m just hoping that it can be addressed in 3.6 which is due to be released in the Spring of 2013.

Screen Options panel

In 3.4.2, actioning the Screen Options link on an admin page would open the screen options panel as expected. However there was no warning for screen reader users that the panel had opened. It was also difficult to find and interact with the options as one had to know to reverse-tab into the panel. Accessing the options this ‘last first’ way was counter intuitive in my view.

As a result of ticket #21326 the Screen Options panel works much better for screen readers now. When the panel is opened, the focus is moved to the first item within the panel so that the items can be accessed in the right order.

Summary

Well that’s all the testing I’ve had time for so far.

Overall I’m really impressed at what’s been achieved, and I’m hoping that real progress on accessibility can be maintained into 3.6 in 2013.

But it does rely on people reporting issues that they find. So if you come across an accessibility problem with WordPress, why not raise a ticket – it’s the only way that things are going to get picked up. If you’re not sure how to raise a ticket see Raising a WordPress Trac Ticket for Accessibility Issues.

And if you’ve got any comments, why not leave them below.

WordPress 3.5 Accessibility Update – November 2012

So which Trac tickets are we talking about?

Some good news

Initial impressions