Title Attributes Galore

The patches for Trac ticket 24766 are slated for addition to WordPress 3.7. This is great news for assistive technology users who have been forced to wade through a sea of unnecessary title attribute verbiage. But we need to ensue that the patches cover all unnecessary title attributes and that those deliberately excluded from the patches do not present any accessibility issues.

Currently, the excluded methods, functions and scripts are:

  • the_author_posts_link()
  • rss.php
  • wp_fullscreen_html()
  • get_adjacent_post_rel_link()
  • _walk_bookmarks()
  • get_image_tag()
  • the_shortlink()

Continue reading

#tabbing, #trac-2, #ui

IRC Meeting: August 7, 2013

A very busy & productive meeting. We’ve identified two high priority areas that we’d like to focus on in the next couple of months.

Continue reading

#media-manager, #meetup, #trac-2, #ui

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.

Continue reading

#accessibility, #add-media, #images, #irc, #keyboard, #markup, #media-manager, #screen-reader, #ui

Accessible Dialogs and Popups

It seems there are an increasing number of areas where dialogs or popup panels are used to alert the user about occurrences and perhaps demand some action from them. Examples include the Autosave and Post Locking dialogs #23697 and Login Expiration #23295 – as pointed out by Joe Dolson.

Within #23697 @azaozz responded to some comments of mine re accessibility by asking “Is there anything else we should be doing to make these dialogs better?”

My response to him was:

  1. When the dialog opens, keyboard focus must be transferred into a meaningful object within the dialog – suggest a heading that explains purpose of dialog. This item can be given tabindex=0 to allow it to receive focus both by scripting and tabbing.
  2. The purpose of the dialog should always be visible.
  3. Whilst the dialog is open, functionality will be needed to tidily cope with users tabbing beyond the controls/buttons in the dialog, or reverse tabbing before the entry point. Tabbing can either cycle within dialog if it’s important that user responds, or that tabbing outside confines of dialog closes the dialog.
  4. Whenever dialog is closed, keyboard focus should be returned to somewhere sensible – maybe the link/button that opened dialog in the first place, or to top of a new page if one is opened.

Does that sum it up, or is there more that could be added to that list?

#core-2, #dialogs, #popups, #ui

WordPress 3.6 alpha Testers

You might want to consider installing the MP6 plugin to get a sneak preview of the new user interface. Thus far, I’ve noted 3 areas of concern:

  1. The contrast on “Collapse Menu” needs to be pushed up a little to #888
  2. Post revision comparisons. Not sure I’m comfortable with red-on-red and green-on-green. At present, the contrasts are way too low at 2.7:1 (heck — even I’m having problems reading the texts).
  3. Ditto the text for inactive plugins on the Plugins page with only a contrast ratio of 2.8:1. And absolutely no way to “highlight” (increase the contrast) on the text without a mouse.

#3-6, #core-2, #ui