So please take a little time, between May 17 & May 31, to have a look at translate.wordpress.org and give us your feedback via comments on this post. In order to support you and provide some structure to the feedback, we’ve prepared a Site Feedback Guide that should help.

We look forward to your contributions.

The meeting on May 1 covered the variations in form handling across different screen readers as well as a recent issue reported with the Jetpack plugin. As a result of the latter discussion, we now have a representative on the Jetpack Beta Group and Trac ticket #1710 has been created.

#wordpress-ui log for May 1, 2013.

On the May 8 meeting, discussion centred on the draft Site Feedback Guide. The guide is intended to both add structure to any site feedback as well as provide some support for non-technical disabled users who would like to join in. We hope to test the guide out later this month.

#wordpress-ui log for May 8, 2013.

3.6 Post Formats

It was previously decided that both the video and audio post formats could benefit from an ability to add links to captions (for videos) or transcripts (for audio files) and some preliminary investigations were started to look at the possibility of submitting patches. However, as there has been some concern about the release schedule for 3.6 and the possibility that Post Formats might be removed from the release, this has been shelved until we hear further.

MP6 Plugin

Attention has now turned to the MP6 plugin and the possible new user interface for WordPress 3.7. Members of the group are now looking for possible accessibility issues via MP6 with a view to helping to remove any problems in 3.7′s interface before they become too deeply embedded.

GlotPress

We’ve been asked to provide feedback on the front end of the GlotPress site and to highlight any areas where accessibility could be improved. The final details for this project — including support for non-technical disabled users who would like to get involved — will be drawn up over the next few weeks.

Theme Accessibility Auditing

We are almost ready to begin some practical testing of the Theme Accessibility Audit. First, both @esmi and @joedolson need to undertake some standard theme reviews so that they can become familiar with the existing theme review process. Once this is complete, we will be looking for some themes to run through the accessibility audit. If you are a theme developer and will shortly be submitting a new, or updated, theme for review, please contact us if you are willing to submit your theme for an optional accessibility audit.

Videos

We are still looking to develop a series of videos demonstrating disabled volunteers navigating around WordPress sites. @accessiblejoe has already recorded a 50 minute screen sharing session with a user of Dragon Naturally Speaking navigating around his own wordpress.com site. Over the next month, this will hopefully be broken down into smaller segments with captions and made available via wordpress.tv.

If you have some experience in recording disabled user testing videos and would like to help us extend the library of videos, please contact us. The more videos we have available, the more we are likely to help all WordPress developers understand the issues faced by disabled users every day.

Extending Pan-Accessibility

It was generally agreed that much of the previous accessibility work within WordPress has focused on visually-impaired screen readers users and that accessibility improvements (and feedback) need to adopt a more pan-disability approach.

Whilst we continue to be very grateful for the invaluable work and feedback provided by some of our screen reader users, we would very much like to encourage users of other forms of assistive technology to become involved. Examples might include switch users, voice recognition users and dyslexics who do not rely on screen reader software.

f you are in one of these groups and would like to help, please join us. We’re quite a friendly bunch and you do not need to have any technical skills beyond an ability to use WordPress and your own assistive software.

#wordpress-ui log for April 24, 2013.

<a href="<?php the_permalink(); ?>" title="<?php echo esc_attr( sprintf( __( 'Permalink to %s', 'twentythirteen' ), the_title_attribute( 'echo=0' ) ) ); ?>" rel="bookmark"><?php the_title(); ?></a>

My question: Is “Permalink to (title of post)” a WordPress anachronism that, by being a redundant title attribute, actually harms accessibility?

Among the changes:

• Images now state that decorative images must be included with CSS.
• Headings explicitly states that post and widget titles must be wrapped in headings, to draw the ‘reasonable headings’ guidelines into a context explicitly relevant to WordPress structure as defined by a theme.
• Link text provides specific techniques for accomplishing the goal.
• Keyboard navigation provides guidance on testing and specific mention of one of the most common failures for dropdown menus.
• Contrast references tools for testing.
• Skip links defines a conforming skip link.
• Forms defines specific changes that can be made to defaults that would break accessibility.

Your comments are welcome.

Thank you.

@lessbloat had kindly had a go at implementing my quick and dirty pragmatic ARIA solution – for which we are truly grateful. Once we’d got access to an environment where the changes were in effect we could see that vast improvements had been made to the accessibility.

I’ll save the detail to the blog post about Add Media Panel but to summarise:

• Keyboard-only users can now tab through the items in the media list and select/deselect using Enter key
• Screen reader users were getting some useful information but possibly only the newest versions can fully use this functionality.
• Voice recognition users can at least use the tab commands to move around the list and select them.

The key decision now is whether the functionality is useful and solid enough to include in 3.6. A couple of extra enhancements would make the solution better for screen reader users – once again see previous post.

My vote would be to run with it if we can get the small further enhancements. We can hopefully address the rest of the accessibility issues within 3.7.  But what do you think?

This is a real problem as the Add Media Panel is such a key piece of functionality.

However, from our IRC chat yesterday the germs of a simple solution may have emerged – a solution that could maybe make the functionality accessible to keyboard and screen reader users. We just need someone to give it a try.

The Problems with the Add Media Panel

Add Media Panel

From an accessibility perspective there are many issues with the 3.5 Add Media Panel. These have been discussed already on this blog – see Add Media Panel – Accessibility Issues, Add Media Accessibility Summary. The trac tickets I raised also contain some discussion too – see #23560, #23561 and #23562

For me however the fundamental problem with the Add Media Panel is that it is not possible to tab to the individual images to select them. This issue means that the functionality cannot be used by screen reader users, or by those who rely on keyboard-only interaction – either directly or via their assistive technology. Voice recognition users will also have a hard job – being forced to rely on mouse emulations if they are available.

To see why this problem occurs, perhaps we should have a look at the markup.

The Current Markup

As it stands, the current HTML markup for the items in the media list looks like this – in this case, a non-selected image in the option to add media from the media library:

<ul id="__attachments-view-58" class="attachments ui-sortable ui-sortable-disabled">
  ...
  <li class="attachment save-ready">
    <div class="attachment-preview type-image subtype-jpeg landscape">
      <div class="thumbnail">
        <div class="centered">
          <img draggable="false" src="http://obfuscated/wp-content/uploads/tower-bridge-011-250x187.jpg">
        </div>
      </div>
      <a class="check" title="Deselect" href="#">
        <div class="media-modal-icon"></div>
      </a>
    </div>
  </li>
...

Although there is a link within the list item, in this non-selected state the link is actually empty and is hidden by CSS (display:none).

So we can see that there is nothing here that can get focus.

When an image is selected the markup does change slightly to:

<li class="attachment save-ready details selected">
  <div class="attachment-preview type-image subtype-jpeg landscape">
    <div class="thumbnail">
      <div class="centered">
        <img draggable="false" src="http://obfuscated/wp-content/uploads/tower-bridge-011-250x187.jpg">
      </div>
    </div>
    <a class="check" title="Deselect" href="#">
      <div class="media-modal-icon"></div>
    </a>
  </div>
</li>

Note that the list item class is updated, and the Deselect link now becomes visible but is still empty. But that doesn’t help selecting a file in the first place.

Could WAI-ARIA Help Here?

The functionality that is being offered here is substantially like a checkbox grouping in a form – to allow a user to select one or more items from a list. And of course, one accessible solution would be to make the list of items into a checkbox array – but that would be a substantial piece of work.

WAI-ARIA defines a way to make rich internet applications more accessible. There are many, many ARIA techniques out there but there is one set that aims to make the browser and assistive technology treat a collection of items as if they were a checkbox grouping even when they are not.

ARIA techniques are recognised by an increasing number of browsers and assistive technologies – including the latest screen readers.

The Building Blocks of a Simple Solution

To use ARIA in this pseudo-checkbox situation we’ll need to add a number of attributes and a new element (adapted from this page on the Mozilla Developer Network):

1. Give the item the attribute tabindex="0". This ensures that the item can receive focus.
2. Give the item the attribute role="checkbox". This tells browsers and AT to treat it like a checkbox.
3. Give the item the attribute aria-checked="false". This states that it is not selected (yet).
4. Give the item an id attribute with unique value – suggest the file id from the database.
5. Give the item a label (linked explicitly by id). This gives screen reader users a prompt for what the item represents – suggest file title. For voice recognition users it would be useful if this was visible.
6. The image in the code fragment above will also need an alt attribute – may be empty of course but must be there.

Currently, selection and deselection are handled by (presumably) jquery routines to interpret the mouse actions. These routines will need to be amended to:

1. Give clear visual feedback when media items have focus.
2. Interpret space bar (and Enter?) presses as toggling the selection on and off.
3. The routines will also need to toggle the state of the aria-checked attribute – from “false” to “true” whenever an item is clicked or actioned by space bar. The reverse should happen if deselection is occurring.

A Suggested Markup Solution

Taking these new attributes into account, the next question is – to which element should they be attached?

One answer may be the file element itself since that is ultimately what is being selected. But I’m not certain about that – what do you think?

So the markup could now be: (new items flagged in red and bold (yes I know – use of colour…))

  ...
  <li class="attachment save-ready">
    <div class="attachment-preview type-image subtype-jpeg landscape">
      <div class="thumbnail">
        <div class="centered">
          <img tabindex="0" role="checkbox" aria-checked="false" id="imgid" alt="" draggable="false" src="http://obfuscated/wp-content/uploads/tower-bridge-011-250x187.jpg">
          <label for="imgid">Tower Bridge at night.</label>
        </div>
      </div>
      <a class="check" title="Deselect" href="#">
        <div class="media-modal-icon"></div>
      </a>
    </div>
  </li>
...

If the image is selected the only change required would be the value of the aria-checked attribute.

In theory these small changes should make it possible for keyboard users to at least select and deselect images for inclusion in their posts/pages and galleries. But we won’t know for certain until someone can prototype these changes.

Can any WordPress devs give this a go so that it can feasibly be included in 3.6?

Any Comments?

If you’ve got any comments about this solution or suggestions for making it better, please let us know. I know that it doesn’t address all of the current accessibility issues with the Add Media Panel, but it’s a start.