How accessible is the WordPress CMS for a blind content manager

As we take great effort to make the front-end of WordPress accessible, the next challenge will be to make an equally accessible CMS. In order to get an impression on this challenge awaiting us I have started a study, together with Jaap van de Putte on how accessible the current CMS of WordPress really is.
A few questions immediately come to mind. During the last couple of years the CMS of WordPress has become more and more dependent on Ajax with lightbox overlays. How do these function for a blind content manager using a screenreader? Can she/he grasp the complexity of the CSM? Is the generated HTML semantically correct and easy to understand?

In my experience as WordPress trainer I have found that the CMS is getting harder to understand for inexperienced content managers. So many options and possibilities. How does this work, if you look thought the CMS pages sequencially, without a quick overview that the graphics provide?

What better way to find out, then to visit a experienced vision-impaired user of computers and screen readers that never ever saw a CMS in his life. Actually, this is not that much unlike most of my seeing clients who want a website and a CMS.

For this I visited Leo Dijk, who works as a legal advisor at the Dutch Ministry of Education, Culture and Science in The Hague. He was kind enough to give me a morning of his time to try out the current CMS of WordPress.

Used software

At this moment there are two major screenreaders: SuperNova by Dolphin and Jaws by Freedom Scientific. Leo uses Explorer 8 with the SuperNova Screenreader version 11.58 on Windows, together with a braille terminal, a standard keyboard and a headphone. This is neither the latest version of Explorer nor the latest version SuperNova, but it is a common configuration for most blind people, especially as updates of SuperNova are expensive. This version of SuperNova doesn’t work well with Explorer 9, nor with Firefox, nor with Chrome. Javascript is executed, however.

Front end experience

For reading the content and structure the front end was good. Tab order was logical and Leo gave StudioPress a compliment about how well the search widget was setup. There where however two important remarks:

Widget titles in Genesis by default have the H4 HTML tag. The content will contain mainly H1 and H2 levels, so an H4 skips the H3 level. This makes the structure of the information less accessible. A H2 for the widget title would be better.

In WordPress images default link to their own image when inserted into content. So, if clicked, the visible window will only contain a single image, and the site only can be recovered by using the back button. A normally sighted visitor can see what is happening and solve it intuitively. But, with a screen reader it is not so obvious. Leo couldn’t interpret what happened and concluded it was a broken link, because neither the title nor the alt tag of the images told him he was clicking a link to an image.

CMS

For normally sighted and visually impaired content managers, the first impression of the CMS is confusing. Much info, what does the jargon mean. As for everybody else an explanation was needed about the difference between a post and a page, the menu-item links, etc.

Tab en item order

With a screen reader, the page is read from top to bottom. The tab key is used to skip from item to item. An easy way to see what the resulting page order is like, is to disable the CSS.

WordPress menu with stylesheet disabled

The semantics of the HTML for adding a post

Main Menu (for the Genesis theme there is an extra link with only the image)

Adjust screen, help e.g.

Title of the action

Publish options

Categories

Tags

Features image

Input title

Input content

Theme SEO (Genesis theme)

Layout (Genesis theme)

Excerpt

Trackbacks

Custom fields

Comments

Slug Author

Menu

A problem for the screenreader user is that the reader could not determine the structure of the list items. What is a main menu item and what a subitem? The reason is that the subitems are placed into separate div’s and not directly into tags relating to their list.

Finding the title input field

The label of the title is placed inside the input field for the title with CSS and Javascript. Hidden without Javascript and with a default style of visibility:hidden. In practice this means that with a screenreader the label is completely ommited.

Finding the content textarea

Using the WYSIWYG editor is obviously impossible. Selecting some text and changing it into a heading for instance is a task that cannot be done with a screen reader. Therefore the default setting must be to use the HTML editor or an editor that uses shortcodes for text markup.

The content text-area also lacks a label and can only be found by searching for the text “uploaden/toevoegen” (Upload/Add) which is just above the input area.

Popup overlay’s

Adding links, inserting images, choosing colours, all work with through pop-ups that break out of the normal flow of the HTML and are not recognised as a popup in a screenreader, they are simply ignored.

Adding media

Inline addition of media with the upload/add option is impossible for a screenreader. But it can be achieved manually, using the menu-item ‘media’ first for uploading images and document and subsequently adding them later via the HTML code.

Conclusion and recommendations

The main issues are:

The input field for the title and the content are currently unrecognizable, they need a label and not just one inside the inputfield

The content manager will need to know HTML, since the buttons for the HTML markup don’t work in a screenreader.

I think this is an excellent post with usefull info. One important point I would make is that the WordPress CMS poses barriers to other levels of ability – not just blind users. Try using it without a mouse for example. And it’s currenlty become slighlty worse in that respect due to increased use of hover.

Hi Robin, thanks for your reply. I am planning to develop a plugin for the WordPress admin to make it more accessible, and your suggestion to add keyboard only access is added to the list of functionality 🙂

I’ve been using WP since 2004 and it really saddens me that the admin panel has become steadily more unaccessible as the years go by. I’m legally blind and generally rely on a screen reader and not only am I working on a site with a userbase that will be predominately visually impaired/blind but I know of a LOT of other blind persons that are interested in using WP since Blogger has become virtually unusable due to their new interface.

I’d love to see the core developers really embrace the accessibility needs, but even a plugin that would help us out would be wonderful.

Hi Cyndy, Thanks for your reply. Good news: A few developers are taking action and are posting accessibility tickets the WordPress trac, and we opened a Linkedin group WordPress Accessibility to discuss issues and solutions. It seems the WordPress code developers are responding positively to add accessibility changes. So myabe from version 3.5 things wil improve. If you want to share your problems please join the LinkedIn group. The more knowledge we have, the better we can come up with solutions.
Kind regards,
Rian

This is very promising. I did see the tickets on Trac; I didn’t really have anything to add to them other than “yes, please” and “me too” so didn’t really see the point in bumping for the sake of bumping. And I’m actually not on LinkedIn, but I may have to create an account to add my $0.02 to all this.