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.
WordPress test environment
In my test account I installed Dutch version of WordPress 3.3.1 with the StudioPress Genesis Framework with one extra plugin: Genesis Translations by Remkus de Vries. All settings and options out of the box. To get started some dummy content and a primary menu was added.
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.
<li class="wp-has-submenu wp-not-current-submenu menu-top menu-icon-users" id="menu-users">
<div class='wp-menu-image'><a href='users.php'><br />
</a></div>
<div class="wp-menu-arrow">
<div></div>
</div>
<a href='users.php' class="wp-has-submenu wp-not-current-submenu menu-top menu-icon-users" tabindex="1" aria-haspopup="true">Gebruikers</a>
<div class='wp-submenu'>
<div class='wp-submenu-wrap'>
<div class='wp-submenu-head'>Gebruikers</div>
<ul>
<li class="wp-first-item"><a href='users.php' class="wp-first-item" tabindex="1">Alle gebruikers</a></li>
<li><a href='user-new.php' tabindex="1">Nieuwe toevoegen</a></li>
<li><a href='profile.php' tabindex="1">Je profiel</a></li>
</ul>
</div>
</div>
</li>
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.
<div id="titlewrap">
<label class="hide-if-no-js" style="visibility:hidden" id="title-prompt-text" for="title">Voer hier de titel in</label>
<input type="text" name="post_title" size="30" tabindex="1" value="" id="title" autocomplete="off" />
</div>
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.
<div id="wp-content-wrap"><link rel='stylesheet' id='editor-buttons-css' href='http://rrwd-demo.nl/wp-includes/css/editor-buttons.css?ver=20111114' type='text/css' media='all' />
<div id="wp-content-editor-tools"><a id="content-html" onclick="switchEditors.switchto(this);">HTML</a>
<a id="content-tmce" onclick="switchEditors.switchto(this);">Wysiwyg</a>
<div id="wp-content-media-buttons"><a href="http://rrwd-demo.nl/wp-admin/media-upload.php?post_id=715&TB_iframe=1" id="content-add_media" title="Media toevoegen" onclick="return false;">Uploaden/Toevoegen <img src="http://rrwd-demo.nl/wp-admin/images/media-button.png?ver=20111005" width="15" height="15" /></a></div>
</div>
<div id="wp-content-editor-container"><textarea rows="20" tabindex="1" cols="40" name="content" id="content"></textarea></div>
</div>
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.
- The semantics of the HTML produced can be improved.
How to make life easier for a blind content manager:
- Change the HTML into a more semantic order like
- the main menu
- input for the title
- input for the content
- publish options
- the sidebar with the extra options
- the help and adjust screen options
- Add a label to the title and content input
- Find a decent shortcode editor te replace the WYSIWYG, plugin suggestions are welcome.
Next step
This test was done using SuperNova by Dolphin. We will look into how Jaws performs in another session.
More idea’s, input, comments and suggestions for e.g. plugins are very welcome.
Thanks
A big thanks to Leo Dijk, for his detemination, patience and enthousiasm.
Icoontjes toevoegen aan links ziet er mooi uit en het is handig voor bezoekers die zien wat voor soort link het betreft, bijvoorbeeld een externe link, een PDF- of Word-bestand.
. 
