I’ve been chatting with Chip Bennett via the Theme Review list about the Theme Audit guidelines. With his feedback (which was from the theme author and reviewer perspective, and very valuable) and the feedback from the comments on my previous post, I’ll be working on the next version with a variety of changes of various types. He’s going to be proposing some changes to the general guidelines that will obviate the need for a couple of the elements in the accessibility audit guidelines.
Updates from March, 2013 Toggle Comment Threads | Keyboard Shortcuts
joe and I’ve been chatting with Chip Bennett via the… - 뉴스 are discussing. Toggle Comments
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.
_Redd, GrahamArmfield, Add Media Panel and WordPress 3.6 – A Simple Solution? - 뉴스, and 2 others are discussing. Toggle Comments
Hey, all. I’ve updated the theme auditing guidelines and they have now been added to the theme reviewer’s documentation. Take a look at the requirements for the #accessibility-ready theme tag and comment back here with any suggestions or changes.
Note that these guidelines are in addition to the rest of the theme guidelines, and there are many quality guidelines already established that don’t need to be part of the accessibility audit.
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.
My response to him was:
- 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.
- The purpose of the dialog should always be visible.
- 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.
- 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?
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:
- The contrast on “Collapse Menu” needs to be pushed up a little to
- 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).
- 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.
We had a little mix-up with the meeting time this week, due to the change to Daylight Savings Time in the US, so this meeting report may be a little shorter than usual.
However, the weekly meetup time remains at 20:00 UTC until the end of the month — when we may review and adjust it. Remember that you can convert UTC time to your local time at Worldtimeserver.com.
If anybody has a chance to take a look at the progress on autosave and post locking that would be valuable – I have some concerns about whether the context changes when sessions have expired will be announced, but haven’t had time to test it at all. Ticket 23295
I think I’ve finally finished! *gasp* Thank you to everyone who provided earlier feedback and jogged my memory.
Is there anything on the completed page I need to re-word or explain in more detail?
As previously, please post all feedback here rather than on the draft page itself.
Another small but lively meeting. We also had the opportunity to welcome our newest member, @shaun_10up – a relatively new core contributor. I think we’ll be keeping him busy over the next few weeks! 🙂
Thanks to contributions from @lessbloat, @ceo and @quanin, we’re now seeing real, positive, progress on Trac ticket #14045. This greatly increases the chance of WordPress 3.6 being shipped with a more accessible custom menu system. Thank you for all of your hard work on this.
As part of the larger WordPress documentation project, I’ve put together a very rough first draft of an accessibility section for the theme developers’ handbook. It still needs a lot of fleshing out as I’m approaching this from the perspective of someone who doesn’t know anything about web accessibility. So I feel that we need to not only tell theme developers what to do but how and why.
That said, is the draft missing anything major — bearing in mind that we do not want to overwhelm theme developers?