The accessibility code standards for WordPress have been added to the core handbook and are open for feedback over the next two week. Also see the Core blog announcement and the draft standards themselves!
Tagged: core Toggle Comment Threads | Keyboard Shortcuts
For the development of WordPress 4.3, we’ve got a handful of major issues we want to work on to create a smoother and more predictable experience for users with disabilities.
Reconcile Heading hierarchy throughout admin & clean-up heading contents
Use Semantic elements for non-link links
Reconcile search methods
WordPress incorporates 5 different search interactions in the admin. For usability, accessibility, and maintenance reasons, this should be made more uniform. We’d like to see this reduced to two basic interactions.
#31818 Uniform Search Form Display/Experience
List table issues
We gathered a ton of data on the List table navigation experience during 4.2, and those are being turned into tickets.
#32028List table pagination: text improvements for screen readers (fixed)
#32150List table: better indication for “no taxonomy” (fixed)
#32152List table: Comments column accessibility improvements (fixed)
#32147 List table: headings for pagination and views links
#31654List tables: Select All shouldn’t be a column header (fixed)
Color contrast issues in admin:
Improve editor experience:
The editor is the single most frequently used part of most WordPress installations – and the experience with this interface should be more consistent.
#29838: Editor focus order issues.
Throughout the cycle, we’ll also be picking away at the dozens of other smaller tickets we want to fix, but these are large issues that will have a deep impact on WordPress, and will require a community effort to make progress.
I’ve made two commits so far to address the fact that row actions (that is, edit/quick edit/trash under each post’s title) only show on hover. I have two questions regarding this that I could your expertise on:
1. In terms of CSS, this is controlled by the visibility property. My understanding has been that visibility: hidden does not get read by screen readers. If this is the case, then we may want to use an alternative method for show/hide. Are these row actions currently in a state where they are useful to screen readers or are they better off not being read (for now)?
2. Right now the keyboard tabbing will only trigger them to show when in the same cell. Should this expand to whenever focus is within the row? I believe visually it is when hovering on the table row.
Just a quick reminder that the next IRC meetup will be on Wednesday, 26 June at 19:00 UTC in #wordpress-iu.
If you have never attended an WordPress IRC meetup before, you can find all of the details you will need to join in the Codex’s IRC page.
One topic for discussion is likely to be the development of a proposed accessibility statement for WordPress. To whet your appetite and give you an idea of what we could aim for longer term, have a look at Drupal’s accessibility statement.
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.
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.
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.
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.
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.
- Should the “Visit plugin site” offsite link (in Plugins → Installed Plugins open in a new window/tab? (A no-brainer?)
- The best way to pre-warn users of an offsite link
Some practical suggestions for the latter might come in very useful right now.
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! 🙂