Add Media Accessibility Summary

Following up on the original post about the Add Media panel, here’s a quick rundown of the functionality issues with screen readers:

  • Cannot select images from Media Library.
  • Media Library images display in list either without description/title (IE) or only the first image is seen within the list (Firefox).
  • A newly uploaded image can be deselected, but no other images can be selected in addition.
  • Cannot activate the Select Files link to upload image in Internet Explorer. (Works in Firefox.)
  • Form fields lack description; show as “unlabeled” in Internet Explorer.
  • Moving through the media panel can take the user (unknowingly) back into the edit screen.
  • Upon “re-entering” the media panel (see previous bullet point), form fields and links no longer seem to work.

I’m sure there are other things that can be added to this list that I’ve missed. (Feel free to edit this as necessary, @grahamarmfield.) Unfortunately, while compiling this list my JAWS went berserk, giving me a bunch of installation errors and then my computer crashed.

#add-media, #screen-reader

IRC Meeting: February 27 2013

As usual, we had a lively meeting. Thanks to all who attended.

Custom Menus

The accessibility of custom menus in WordPress 3.6 and its related Trac ticket continued to be the main topic of conversation. This is undoubtedly going to be a very difficult area to get just right — not only in terms of the coding approach but also due to the problems of ensuring that screen reader users are presented with a meaningful construct when they try to manipulate menu items. Because of this, it was felt that there was a real danger of theoretical discussions taking priority over the development of prototypes. To try and avoid this, @GrahamArmfield and @lessbloat have agreed to take the lead together on developing prototype solutions.

Add Media Panel

@GrahamArmfield recently raised some concerns over accessibility issues within the current Add Media Panel and we decided to progress further with this. @ceo agreed to post a summation of the issues faced by some screen reader users shortly. Some possible new options were suggested such as an ability to tag images and filter the library by tag or an option to filter the library by upload date. Both may offer some benefits to users trying to locate a specific file in a large library when they are unable to “see” the images in question.

Join Us

Finally, a reminder that we are still a relatively small group of active members (although we have 156 people subscribed to this blog by email). We do need more active members – both technical and non-technical. So do please consider joining the group.

#wordpress-ui log for February 27, 2013

#irc, #meetup, #menus, #twentythirteen

Add Media Panel – Accessibility Issues

I’ve raised this post as I feel that the issue of the Add Media panel accessibility needs some debate amongst the accessibility community.

Last week I raised three WP trac tickets covering my take on the problems from the keyboard access, screen reader and VR aspects. They are: #23560 and #23561.

The main problem as I see it is that it is not possible to select/deselect any of the media without using a mouse.

The functionality primarily acts like a group of checkboxes – selecting one or multiple elements, with feedback that they have been selected. However, that is not how the functionality has actually been implemented – it’s a series of divs contained within an unordered list. There appears to be nothing to receive focus. There are links for each file, but the links appear empty although they are used to show the selected icon. These links are also initially invisible using CSS techniques that hide them from screen readers – hence the no tabbing into the images issue.

Is the use of ARIA going to really be able to help here?

When mouse users select an image they can update the attribute values for that image using the panel to the right – which updates its content automatically. Allowing keyboard users to quickly reach the attributes boxes would obviously be desirable – the alternative being tabbing through all the previously uploaded files.

The media selector panel has been implemented with infinite scrolling, so on mature and/or larger sites with many images/files (I have one) the list of images gets bigger and bigger. From an accessibility perspective I’d favour paging over infinite scrolling, but what’s your take on that?

Is this another area where bending the new functionality to include accessibility might be too much? Is this another place where an accessibility mode is going to be required?

What do you think?

#accessibility, #add-media, #images, #keyboard, #screen-reader

Captions on

Hey folks. I posted the long description on the docs blog since they’re the product team responsible for all the text stuff:

We’re adding closed captions to videos, so will be recruiting volunteers to create caption files (and others to review them for accuracy). The feature is ready and will be launched quietly on Monday. Will need a volunteer to head up the captioning corps (so to speak) under the aegis on the docs team. If anyone here is interested, please head over to the post linked above to express interest.


#captioning, #transcripts

IRC Meeting Summary: 20 Feb. 2013

As evidenced by our small group at yesterday’s meetup, I want to first remind you all that we could very much use new members! Whether you are a developer and very technical or merely a writer with special needs, we would certainly welcome you to join us. Anyway, despite our numbers and lack of a formal agenda, our main discussion was on two topics that will be our primary focus presently.

Custom Menus

As the trac ticket concerning design changes to the Custom Menu has been closed, we discussed centering accessibility discussion around the reopened trac ticket #14045. The proposal is for an accessibility mode screen alternative like that which the Widgets page utilizes. We also have a post devoted to this topic here as well for your consideration and comments.

Twenty Thirteen

Feedback is strongly requested from an accessibility standpoint on the new default theme Twenty Thirteen, which is currently being developed. You can check out the theme here at the Twenty Thirteen demo site and please report any feedback you have.

The full log of yesterday’s IRC meeting can be found here at #wordpress-ui logs for February 20, 2013.

#core-2, #irc, #meetup, #menus, #theme, #twentythirteen

Twenty Thirteen

Development on the next default theme — Twenty Thirteen — has now reached a point where our feedback is needed. You can see and use the theme (currently still in alpha) at its own Twenty Thirteen demo site.

Please post all feedback here. If you are using assistive technology to browse the demo site, please indicate exactly what software you are using — including the version number, if possible.

Come on, people. If you want a truly beautiful example of an accessible WordPress default theme, now is the time to point out any issues and support the theme’s developers.

#a11y-audit, #core-2, #theme, #twentythirteen

Creating Custom Menus

There is a lot of discussion and design going on at present concerning the changes that are being made to the Custom Menu Builder for WordPress 3.6. These discussions can be followed via trac ticket #23119.

But as part of that work the Custom Menu Builder needs to become easily accessible to those who can’t use a mouse, or who are using screen readers or speech recognition software.

During our IRC sessions this week and last we touched on potential solutions. So far the solutions have boiled down to:

  1. Use a separate accessible version in a similar way to how the accessible widgets functionality works.
  2. Ensure that the rebuilt functionality, which will almost certainly feature drag and drop contains and generates enough information to allow easy manipulation by those using assistive technology.
  3. Ensure that the markup of the solution externalises enough information about hierarchy and makes influencing it easy.

But we need some more input on how this functionality could be deployed accessibly.

Although the widgets method is usable, could it be better? If so, how.

Could a drag and drop solution with ARIA help really work for blind users?

Please feel free to comment with any ideas you may have.

Post Revision Timestamps

Following a suggestion from @Ryan McCue about making timestamps in post revisions human readable, I’ve set up a test case that uses both human readable and W3C recommended timestamp formats.

All feedback and comments here, please.

#markup, #testing

Spawning New Windows/Tabs

Sorry for the flurry of posts but there’s an important discussion going on in re-opened Trac ticket #20839. The current discussion is focusing on:

  1. Should the “Visit plugin site” offsite link (in Plugins → Installed Plugins open in a new window/tab? (A no-brainer?)
  2. The best way to pre-warn users of an offsite link

Some practical suggestions for the latter might come in very useful right now.

#core-2, #links

Post Revisons Update

I managed to drop into the Core IRC meeting yesterday and was told that the our recent feedback on the new concepts for post revisions was very helpful. New screenshot mockups have now been created to incorporate fixes for the issues that we raised.

Coding on the new post revisions may begin shortly, so let’s keep an eye on the outstanding tickets and new developments. In the meantime, thank you to everyone who took part in the post revision discussion and let’s keep up the good work.

We can make a difference! 🙂

#core-2, #revisions