Add Media Panel and WordPress 3.6 – A Simple Solution?
The beta version of WordPress 3.6 is very close now and the chances of significant extra functionality being included must be slim. But, the Add Media Panel introduced in 3.5 is still inaccessible and the trac tickets raised on this are still untouched.
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
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 (
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):
- Give the item the attribute
tabindex="0". This ensures that the item can receive focus.
- Give the item the attribute
role="checkbox". This tells browsers and AT to treat it like a checkbox.
- Give the item the attribute
aria-checked="false". This states that it is not selected (yet).
- Give the item an
idattribute with unique value – suggest the file id from the database.
- 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.
- The image in the code fragment above will also need an
altattribute – 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:
- Give clear visual feedback when media items have focus.
- Interpret space bar (and Enter?) presses as toggling the selection on and off.
- 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
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?
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.