Digital Accessibility Centre Visit – Part 1: Introduction, Keyboard and Dragon Testing

On February 25th 2014 I was honoured to visit the offices of the Digital Accessibility Centre in Neath, South Wales, UK. The trip was organised by fellow wpa11y team member Siobhan Bamber.

This post is the first in a series of three which summarise the feedback we received on using WordPress from three users with impairments. Our first session was with Becs who uses Dragon NaturallySpeaking (voice recognition software) and does keyboard accessibility testing.

 

What is Digital Accessibility Centre?

The Digital Accessibility Centre (DAC) is a non-profit social enterprise who employ many people with disabilities and impairments to do accessibility end-user testing.

Gavin and Cam from the DAC had offered us the time (at no charge) to talk to some of their employees and get their feedback on the accessibility of the WordPress, and for this we are extremely grateful.

Given that the accessibility of a WordPress website is a product of the accessibility features built into the theme and the quality of the content added by the authors, we decided to garner feedback on the admin screens within WordPress. The version of WordPress tested was 3.8.1

We spent time with three different people – Becs, Gary and Carly. Each have their own specialities when end-user testing, based primarily on their own impairments. They have all been with DAC for some time and are experienced accessibility testers.

None of the people we spoke to were really conversant with the WordPress admin area, so some of our time was spent explaining how it all worked. We covered the key functions of adding a new post into a test site, and where time allowed, trying to add images and manipulate custom menus, and investigating other areas.

The notes I’ve made here were taken directly from the comments each person made, but I’ve also annotated where further action might be required from the WordPress Accessibility Team. Subsequent to the visit I’ve carried out some more testing to try to increase my understanding of what’s actually happening in certain situations.

Becs: Motor Impairment – Keyboard and Dragon NaturallySpeaking

Becs was the first person we spoke to. She experiences some motor impairment and specialises in testing using a keyboard, and with Dragon Naturally Speaking (voice recognition software). Her comments were as follows:

Visible Focus

Focus indication appears absent or way too subtle – especially for check boxes. Ideally need more of a colour change, and/or showing underline on links. (Action: need trac ticket raised if not already there).

Highlighting of Help and Screen options buttons is too subtle.

Subtle changes of colour may not be noticed, at the very least, keyboard focus should be as visible as mouse hover, but mouse hovering is easy because the user is in control, and can see where they are placing the mouse – this is not so for keyboard users.

Poor focus indication on OK button when influencing Publish date in Edit Post screen. (Action: is there a ticket that includes this?)

Keyboard Operability

The link to existing content in Insert/Edit Link panel – cannot get focus. (Action: Has this been raised as a trac ticket yet?)

Not surprisingly, the Add Media functionality seems to be mainly a mouse only experience.

Becs was impressed how the Theme Customizer keyboard accessibility was good (although not in Dragon), and especially impressed with the fully keyboard accessible colour picker – although she felt that some instructions would be useful. Focus indication on the preset colour blocks beneath the colour picker is not good.

Tab order

In Becs’ view the overall tab order of the WordPress admin screens would seem confusing for keyboard users – would expect toolbar first, followed by navigation, then main content.

The existing tab order in the add/edit post/page screen is also confusing to people. I explained why I think it’s been done, but Becs wasn’t convinced.

In all cases, she felt strongly that tab order should follow what’s visible on the screen. She also felt it was confusing and not at all intuitive to have to reverse tab to reach the Add media button and the Change Permalink button in the Edit Post screen.

Posts Table

The tab order of main posts table (which is: header row, then footer row, then content) caused Becs some real consternation. I understand this is an orientation thing, but is this really needed? And if so, could this perhaps be turned on/off as a configurable option by the user? (Action: Discuss)

Becs also asked why quick links weren’t all visible all the time. I explained that this could significantly multiply the number of links that would appear in links list for screen readers. Becs accepted that but thought it would be useful to include reference to these links and why they weren’t always visible in the accessibility statement.

Showing links on a page with Dragon

Dragon commands “link” or “click link” shows all links etc, but there is a limit on how many can be shown at once with dragon. Apparently Dragon has a limit of 50 for links or text boxes, etc. This means that links beyond the 50th link on a page cannot be referenced in this way.

In main admin left hand menu, when Becs gave the “link” voice command, all the numbers in the left hand navigation appeared to be misaligned – they appeared to be higher than they should be. This would lead to her voicing the wrong link, and wondering why Settings doesn’t have a corresponding number.

However, subsequent investigation on my own machine didn’t produce the same results – for me the numbers and links were all perfectly aligned.

(Action – Need to investigate what was going on there.)

Please note: the listing of all links on a page is not the only way that Dragon Naturally Speaking users can interact with links, they are able to use voice commands that include the link text – eg “Click Tools”.

Dragon and TinyMCE

Becs had some problems with formatting text and adding links when editing the content of a post using Dragon.

Using Dragon voice commands, it is possible to select some text in the editor box. However it appears not to be possible to apply formatting, even though the formatting ‘buttons’ can be accessed when the “Link” command is issued.

Becs’ method in full:

  1.       Cause Dragon to select some text using the “Select ____ to _____” command.
  2.       “Link” to show numbers against each of the buttons.
  3.       “Choose ___” to ‘click’ the relevant ‘button’ to apply the formatting.
  4.       There is no change to the selected text.

It appears that the selection made by Dragon is somehow not recognised by Tiny MCE.

This is further supported when trying to add a link.

Becs’ method:

  1.       Cause Dragon to highlight some text using the “Select ____ to _____” command.
  2.       “Link” to show numbers against each of the buttons.
  3.       The ‘Insert/Edit Link’ button is not enabled – so cannot be actioned.

There was not enough time during the session to explore further what was happening here. But subsequent experimentation makes me wonder if maybe TinyMCE is listening for mouse clicks or keydown events to trigger actions, and the text selection with Dragon fires neither of those. (Action – needs further investigation.)

Dragon and Modal Overlays

Becs did get to try to add a link using keyboard operation. However, when the link overlay appears, Dragon appears initially not to be able to reference the input fields.

She felt that this could actually be a z-index issue, and we discovered that the situation crops up pretty much everywhere that the modal overlays appear – including Add Media. I’m told that when Dragon is labelling the input fields (or links, etc), the numbered labels appearing next to the links, text boxes, etc have a z-index of (believed) 100. So they may be present, but beneath the overlay panel.

Subsequent investigation shows this to be the case. The modal overlays in WordPress don’t have consistent z-index values, but that they are all substantially more than 100. Testing using a combination of keyboard and Dragon, it’s possible to guess correctly the number to choose to place focus into a text field. Manually closing the modal reveals that Dragon’s number pointers are present in the correct place, but were just obscured by the modal.

See this example using the Insert/Edit Link modal.

Insert/Edit Link modal box when first opened

In the first view, I’ve highlighted some text using keystrokes, and then commanded Dragon to “Insert edit link”. The modal has appeared and I’ve then voiced the command to “Click type text” to get Dragon to indicate all the text boxes. But note that only the two in the original Edit page appear to have the number indicators.

Insert/Edit Link modal dialog box after successfully guessing the correct number.

In the second view, I’ve guessed that the ‘Title’ text box is number 4 and have voiced “Choose 4”. Note that I guessed correctly as focus has now been transferred into the ‘Title’ text box.

Insert/Edit Link modal has been closed revealing the DRagon number indicators beneath.

The third view shows what becomes visible when I close the modal using a mouse click. The Dragon number indicators are now all visible and the fourth one is red, showing it is the currently selected one.

(Action: Investigate further about the z-index of the Dragon number indicators. Also investigate if the WP Admin modal z-index values need to be so high?

General

Becs’ recommendation is that the WordPress admin should have some kind of page for AT users to explain what’s going on – maybe in an overall Accessibility Statement. But also we may need an accessibility help page for every page/function in admin. (Action: We need to discuss whether this would be a good idea, and how it would be feasible.)

Becs was impressed with the presence of skip links within the admin area.

Miscellaneous

The various ‘Add new’ links could have more context within the link text to make them easier to action directly.

When using Dragon to add the title to a new Post or Page, The label prompt in the Title field does not disappear as you might expect. This results in a horrible jumble of letters – something that doesn’t occur when using a mouse or pure keyboard access. (Action: Investigate this.)

Using Dragon, entering the post title does not cause the label to be removed.

Using Dragon, entering the post title does not cause the label to be removed.

#accessibility, #assistive-technology, #feedback, #keyboard, #voice-recognition