WordPress 3.5 Accessibility Update – November 2012

Published: | 10 Comments

Reading Time: 6 minutesWordPress LogoBack 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 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.

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

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.


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.

Other Accessibility posts

Share this page (Links open new windows/tabs)

  • Share this page on LinkedIn (opens new window)
  • Share this page on Delicious (opens new window)
  • Share this page on Digg (opens new window)
  • Share this page on Posterous (opens new window)
  • Share this page on Reddit (opens new window)

10 Responses to “WordPress 3.5 Accessibility Update – November 2012”

  1. From: Graham Armfield on November 26th, 2012 at 8:56 am

    Further changes have been made since the original post. The skip links have been recoloured to dark grey text on light background after it was pointed out that the white on light blue did not provide enough colour contrast.

  2. From: Rachel McCollin on November 26th, 2012 at 10:08 am

    Hi Graham,

    Thanks for the update, it’s great to see that progress is being made. It will be interesting to see if there are any more accessibility enhancements before 3.5 gets its final release (although with that being so close I guess it’s unlikely) – let’s hope some progress is made on the menus screen, which I agree is an important feature and needs to be accessible for all.


  3. From: Graham Armfield on November 26th, 2012 at 10:15 am

    Hello Rachel,

    There have been a couple of developments since I wrote the post just over a week ago – specifically in the skip links colour scheme and the keyboard accessibility of Theme Customizer.

    There may already have been some other improvements in other areas but I’ve not had a chance to do an extensive test. In the new year I’m hoping to do a much more detailed test and to document the full extent of the changes.

    The Custom Menu functionality is flagged for early in 3.6 now, along with some other work to ensure things work nicely with speech recognition software.

    Best wishes

  4. From: Justin Romack on November 27th, 2012 at 11:54 pm

    Excellent! Can’t wait to see some of these accessibility improvements in action. Must say – the funkiness with screen options always threw me for a loop, so it’s nice to see that getting some attention.

    Thanks so much for this overview, Graham!

  5. From: Rachel McCollin on November 28th, 2012 at 7:52 am

    Hi Graham,

    Thanks for that. I have another question. My personal site is run on MultiSite and I’m finding it difficult to access the Network Admin page on a touch screen, because when you click on the Dashboard link, it takes you to the child site dashboard and doesn’t display the submenu for long enough because there’s no hover state on a touch device. Is this an issue for accessibility, I.e. is this something you can only do with a mouse?

    If you’ve never come across this please just tell me to research it myself or raise a trac submission – I know you’re a busy man!


  6. From: Graham Armfield on November 30th, 2012 at 8:50 am

    Hi Rachel, thanks for your comment.

    Actually I don’t have any real knowledge about Multisite – I guess I’ve never really understood what benefits it could bring to me and to my clients. Perhaps you could advise on that…

    The issue of dropdown menus and touch devices is a tricky one – as I have found on some client sites. The most recent sites that I’ve built contain dropdown menus, but I’m actually preventing the dropdowns from appearing on touch devices as it’s been frustrating the clients that the dropdown menu appears only briefly when you touch a top-level link. And even if you are quick enough to retouch, it’s probably too late.

    In my view, the key here is to ensure that context-specific sub menus are provided on the pages as appropriate. That way, touch users can navigate to all the pages on the site. If the only way to get to somewhere is via a dropdown menu then some areas of the site are probably off-limits for some users (inc touch users). This is an accessibility issue, as there is a specific WCAG2.0 success criterion (2.4.5) about providing multiple ways to get to content on a site.

    It sounds as though the Multisite Admin screens would fail this guideline then if the only way to get to a certain admin page is via a dropdown menu. I’ve been involved in discussions with WP devs about the Log out link – something that is currently only accessible via a dropdown menu. There has been some progress on that but nowhere near what I really would have wanted to see.

    So Rachel, I would say that the difficulty in reaching that admin screen in Multisite would be worth a trac ticket. It’s not strictly an accessibility one but it sounds like it probably would be too.

  7. From: Progress in WordPress Accessibility | David A. Kennedy's Blog on December 4th, 2012 at 2:28 am

    […] Armfield has updated everyone on all the recent work in core regarding accessibility tickets. And the Community Summit generated good discussion on potential future […]

  8. From: Kelli Wise on December 13th, 2012 at 6:10 pm


    Thank you for all the work you do with the WP core team on this.

    I have a client who had been having a difficult time getting a website designed for her because she’s blind. I will be doing all of the design and setup for her, but she will be updating content, blogging, etc once my work is done. Is the admin area really accessible for users who want to update content and not fuss with settings, menus and the like? Is there an admin theme available that would make WordPress a viable solution for her? Keep in mind that she is a web novice.

  9. From: WordPress Development in 2013 - Rachel McCollin on January 10th, 2013 at 11:49 am

    […] of them, as you can see from the trac listing, closed. Graham has provided an update on progress on his website and it’s great to see advances being […]

  10. From: Progress in WordPress Accessibility | David A. Kennedy on May 1st, 2015 at 12:34 am

    […] Armfield has updated everyone on all the recent work in core regarding accessibility tickets. And the Community Summit generated good discussion on potential future […]

Like to leave a comment?

Please note: All comments are moderated before they will appear on this site.

Previous post:

Next post: