Digital Accessibility Centre Visit – Part 3: The Blind Perspective

This is the third post documenting a recent visit to Digital Accessibility Centre in Neath, South Wales organised by fellow team member Siobhan BamberThe first post can be found here, and the second post here.

Three of the staff from DAC gave us feedback on using the WordPress admin screens. Each of the three have a particular impairment, and the visit was a valuable opportunity to learn about ways we could improve WordPress for everyone.

In this post we take feedback from Carly who is totally blind. She showed us how she used a screen reader and gave us some great feedback on using the WordPress admin screens with a screen reader.

Introduction

Carly is blind and uses screen readers to access websites – usually JAWs but also NVDA. She tried out the admin with JAWS – it’s all we had time for.

She showed us both browsing in context and out of context.

In context means getting the screen reader to read text, links etc whilst moving around the page. Out of context means using the screen reader commands to list all links, buttons, headings etc on a page. This latter method is extensively used by blind people.

Out of context commands for JAWS

  •         Ctrl+ins+b gives list of buttons on page
  •         Ins+F7 gives list of links
  •         Ins+F6 gives list of headings
  •         Ins+F5 gives list of form fields
  •         Ctrl+Ins+G gives list of images

 

Link and button text

Add New links appearing in JAWS links list

Add New links appearing in JAWS links list

There are many links labelled “Add new” in the left hand menu. This is not enough to fully describe the purpose of the links – although educated guesses can be made here. Carly said that link text must give context so that it’s easy to know what the link is for, otherwise you have to guess. (Action: Discuss and maybe raise ticket to get more context added to these links.)

Carly also commented on the Edit links in the Publish box. They need more context. I told her that was coming in 3.9 – see ticket 25459

It is important to let people know when a new panel or window is to open – eg Add Media (Action: Identify where this is not happening and raise tickets)

Headings and orientation within pages

Listing headings on the page reveals the page structure. Carly indicated that she thought getting the heading hierarchy right was important as it indicates to screen reader users how the content fits together.

Using the full set of landmark roles would be a good thing too. (Action: Raise ticket)

Letting user know when things have happened

When adding tags in a new post, screen readers need to have audible feedback that they’ve been added. Same with Post Added/Published etc.

Audible feedback would also be useful in the Custom menu area to identify when items have been added to a menu, or when the menu hierarchy has changed.

In fact any action in the WP Admin needs to have some audible feedback. Where things happen within the page without a refresh maybe ARIA live regions could help. (Action: we need to discuss strategy. Once strategy defined we can raise tickets for each instance where it would help.)

Input fields and fieldsets

Carly commented on the Post format radio buttons when she was adding a post as she had no idea what they were for. Any radio buttons should be contained within a fieldset, so that the legend can describe the context for the radio buttons. (Action: Agree strategy and raise tickets.)

Tab order

We were using the Edit Post screen in one column mode after we’d changed it in Gary’s session. Carly obviously didn’t notice, but it highlighted to us how seemingly random the tab order is in the Edit screens as she was tabbing around. (Action: Discuss and potentially raise ticket.)

Add media

If a screen reader user uploads an image or media file with the 3.8 Add Media panel it is possible to add it into a page/post if it’s all done in one step. We asked Carly to upload a PDF file and make a link to it from a page. She was able to upload the file but couldn’t work out how to successfully place a link to it on a page.

Carly’s inability to complete this points up that some instructions are required – even for sighted users this actual task can be a bit confusing. See note in first post about accessibility pages.

As we know, doing anything else in the Add Media panel with a screen reader and keyboard only operation is not currently possible.

Custom menu editor

Carly had a go at creating and manipulating a custom menu. Instructions would really be needed here – I had to explain how to do it. She says that it needs audible feedback that menu items have been added, or hierarchy changed etc (see above).

Recommendation: The individual custom menu items should be marked up as accessible accordions so that blind users know that there are options that they can influence. (Action: Discuss strategy and raise appropriate tickets.)

Whilst Carly was in the Custom Menu area, Siobhan and I noted that visible focus is poor with some of the elements. (Action: Maybe a ticket required if one hasn’t already been created.)

Widgets accessibility mode

On my suggestion, Carly briefly tried the accessibility mode in the Widgets area. She was able to manipulate widget options, but things got difficult when we got to the table where she could influence the positioning of the widget within the available widget areas.

The combination of the radio buttons and dropdowns in the table was confusing and there were no real instructions (help required). Carly didn’t really know what was expected of her – even with me explaining – as the context for the dropdowns (selects) is provided by the table column heading and the adjacent radio button instead of a true label.

Behaviour between screen readers can differ here but the situation in both JAWS and NVDA is less than perfect. Ideally, the radio buttons should be in a fieldset, but if table structure precludes that, then more context must be added to radio button labels. (Action: Investigate more fully, discuss solutions and raise trac ticket to improve the situation. Definitely requires some better instructions to explain to people what is required.)

Conclusions

Just this brief exploration of the WordPress Admin area with three people with impairments and their assistive technology has yielded some important lessons, and pointed out some ways that WordPress accessibility can be improved.

I’m hoping that we can post some proposals for our ongoing accessibility strategies here soon.

#accessibility, #assistive-technology, #feedback, #jaws-admin, #screen-reader, #testing, #trac-2