stomme_poes — 2012-03-23T18:24:04-04:00 — #1
Rian Rietveld and Jaap van de Putte have done a brief study/test on the admin side of a typical WordPress installation, the results of which are pretty interesting!
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.
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.
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
- Features image
- Input title
- Input content
- Theme SEO (Genesis theme)
- Layout (Genesis theme)
- Custom fields
- Slug Author
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 href='users.php' class="wp-has-submenu wp-not-current-submenu menu-top menu-icon-users" tabindex="1" aria-haspopup="true">Gebruikers</a>
<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>
Finding the title input field
<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" />
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 id="wp-content-editor-container"><textarea rows="20" tabindex="1" cols="40" name="content" id="content"></textarea></div>
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.
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.
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.
A big thanks to Leo Dijk, for his detemination, patience and enthousiasm.
Leo Dijk, a blind legal advisor at the Dutch Ministry of Education offered to be a test subject for the WordPress tests. He uses the SuperNova screen reader (when Rian says there are two major screen readers, (Dolphin) SuperNova and JAWS, she means in the Netherlands. I guess Window-Eyes isn't big here).
The mistakes are basic (using separate divs instead of a nested ul for a menu), while some are things that are becoming trendy (the label for an input being hidden by default, lightboxes). Very interesting.
In the Web Accessibility group on LinkedIn a user commented that he tends to do okay with WP but mostly because he does everything manually, by typing code instead of choosing things. Hm...
sojankf — 2012-03-24T06:30:31-04:00 — #2
It is a nice experiment and may be it changes the design systems.
mat30 — 2012-04-03T16:56:48-04:00 — #3
Although I'm not Wordpress's biggest fan, so I don't use it, would a well developed admin theme be able to improve its accessibility? It should not need to, I know, but there you go... Actually, that's one of the things in Drupal's favour: the overlay can be turned off; most (maybe all) of the JS is not strictly essential; and the back-end can be themed as much as the front-end if necessary (though it's not).
stomme_poes — 2012-04-04T03:31:44-04:00 — #4
Looking at the problems, it seems a whole lot of problems could be removed simply by changing the HTML of the admin panel, smarter CSS, and being more careful with lightbox-like overlays (those are still a problem, I'm still not sure the best way to make those accessible... you can use roles and manually set focus traps, but this still misses older browsers/AT and is a whole lot of work that, frankly, should be taken care of not by the developer but the browser).
rguy84 — 2012-04-12T12:17:20-04:00 — #5
I saw this link the other day, while it doesn't do anything huge right now, it is a start. It will be interesting to see where it goes: http://www.coolfields.co.uk/2012/04/wordpress-admin-menu-accessibility-plugin-version-0-1/
rianrietveld — 2012-05-18T23:43:02-04:00 — #6
Hey @stommepoes, thanks for posting this! In the meantime we did some more testing of the admin of WordPress, with different screen readers on different browsers. Some problems are indeed easily solved by a smarter set up of the HTML/CSS.
Quite hilarious is the fact that the option for selecting the accessible display for the widgets is hidden by CSS.
Others are not so simple, like getting the Appearance -> Menus working without a mouse.
Work in progress...
rianrietveld — 2012-05-18T23:44:01-04:00 — #7
Hi @rguy84, thanks for the link to the plugin, will look into it!
rianrietveld — 2012-06-28T01:54:09-04:00 — #8
If you are interested in helping making WordPress more accessible: the LinkedIn Group WordPress Accessibility started this week.
Feel free to join if you want to add your views to the discussion.
webcrawler — 2012-09-07T10:52:00-04:00 — #9
Due to full support of HTML5 in latest WordPress releases, I think its somewhat difficult to do full fledged Accessibility implementation in WordPress without hacking the core codes.
rianrietveld — 2012-09-10T02:28:15-04:00 — #10
That's why it's so important to let the developers of WordPress know what the accessibility problems are. They are most helpful. You can post tickets describing the issues you have on the WordPress Trac. One problem per ticket. On http://core.trac.wordpress.org/search?q=accessibility you can see all the tickets that have been made so far. A lot of these will be solved and implemented in to the next WordPress versions.
webcrawler — 2012-09-10T02:31:24-04:00 — #11
yes, i am aware of this initiative from LinkedIn WordPress Web Accessibility group
stomme_poes — 2012-10-02T15:41:51-04:00 — #12
To anyone attending the next Fronteers conference in Amsterdam this year:
Rian Rietveld will be giving a lighting talk at the Jam Session about WP Accessibility.
If there ends up being any videos taken, I'll post them here.
marx_melencio — 2012-11-01T05:15:49-04:00 — #13
Hi. I'm Marx, and I'm totally blind. I use JAWS For Windows and the latest Wordpress CMS version (as of this writing). Here are a few suggested JAWS For Windows version and Web browser combinations that could help JAWS For Windows users when navigating through the Wordpress admin panel and using its features:
=>> Use IE 8 (or later), Firefox or Google Chrome and JAWS For Windows 13 for recent Wordpress CMS versions;
=>> Use Firefox and JAWS For Windows 11 for recent and older Wordpress CMS versions; and
=>> Use IE 8 or Firefox and JAWS For Windows 11 for older Wordpress CMS versions...
That's about it. I don't have any problems using any of the combinations above. I have JAWS For Windows 13 installed and use IE 8, Firefox and Google Chrome in my laptop. I have JAWS For Windows 11 installed and use IE 8 and Firefox in my desktop computer. Hope this helps...
stomme_poes — 2012-11-02T05:52:11-04:00 — #14
Marx, have you given NVDA a try?
Also, I seriously want to know how you're using Google Chrome with JAWS. Last time I tried, some things read out but others didn't. I couldn't navigate but I could read text. That was likely several Chrome versions ago since they seem to update every minute.
In general: Fronteers has started posting videos: http://vimeo.com/51897008
During the talk I found Rian to sound a bit too quiet (this took place in a bar, though we had that whole level to ourselves) and I noticed people talked more during her talk than during others.
marx_melencio — 2012-11-02T06:19:20-04:00 — #15
Hi Stomme Poes,
Yes, I have used NVDA just to try it out, and I prefer JAWS. I even recently downloaded and installed NVDA again, because the NVDA team is arriving here in Manila on Monday, and they invited me in the conference, because they would want to hear about things that they can do to improve the overall performance and functionality of NVDA. Will try to update this thread about the things we'll discuss in the conference...
I use JAWS 13 with Google Chrome, its most updated version. Aside from toolbar functionalities, which I need to use the JAWS cursor to access, everything works out just fine...
stomme_poes — 2012-11-02T17:58:39-04:00 — #16
Good to know, and nice that Chrome is finally becoming usable. Now for Opera...
So Jamie and Mike are going to the Philipines?? Yes, updates would be very cool.
By the way I think you should get in contact with Graham Armfield and Rian Rietveld, who are both working on accessible amin-areas for Wordpress, because they'd probably want to hear your results or do some tests. They're both on LinkedIn and Twitter but I'm not into WP myself so I don't know all the WP groups floating around on the web. I could also contact them (I don't think Rian visits SitePoint enough to see if this thread gets replies).