Planning Theme Accessibility for 2015

At WordCamp San Francisco, several members of the community including members of the WordPress Accessibility team met to discuss the future of accessibility for plugins and themes in repositories. While the accessibility-ready theme tag has been successful, it only scratches the surface of the long-term goals for accessibility in both environments.

Discussion of issues within the plug-in repository were brief; essentially, the plug-in repository is seen as a jungle, and we’re not really prepared to tackle that beast. However, the accessibility of themes is something that we can address, and that’s our goal in the coming year.

At the community summit, we worked out a roadmap for meeting these goals, with a target of making some level of accessibility a requirement in order to submit a theme into the theme repository.

The primary tasks along the way include authoring code examples to be housed in a community GitHub repository, authoring tutorial documents and detailed guides to help authors meet the requirements, and providing training to theme reviewers to help handle these requirements.

But there are a lot of details left to be worked out, and people to get involved in the process.

We’ll be having a meeting in the Accessibility channel for WordPress at 16:00 UTC on Thursday, December 4th to discuss goals and assign tasks. If you’re interested, please attend!

Basic Agenda

  1. Updates on progress from those already working on the project.
  2. Talk about timeline for goals
  3. Discuss written documents needing to be prepared
    1. Where they should be published
    2. Who will write them
    3. Editorial process
  4. Discuss theme author and reviewer training

WordPress Accessible Themes Roadmap

Initial Proposed Timeline

What When
Initial content (3 initial steps) December 12 2014 Published Dec. 15, 2014
All resource copy written Late January 2015
Code library finished Note April 2015
All accessibility info published in various locations (See below) April 2015
All new themes to automatically be tested for accessibility November 2015

Brainstorm of Content Types

We felt that the following pieces of information should be provided for theme dev (and others) to help them understand the reasons why accessibility is so important, and how to actually go about bringing accessibility techniques into themes.

  • The 3 steps – the top 3 things to do to improve accessibility within a website. These are:
    • Keyboard navigation
    • Controls that aren’t controls
    • Unidentified images
  • A resources page – “A  way in”
  • The WordPress Accessibility Guidelines – what WordPress defines as being accessible
  • A world map of accessibility legislation
  • Landing pages
    • on Make WordPress Accessibility (
    • on WordPress main site (
  • Why accessibility is important – prose + video
  • How to do accessibility – prose + video
  • Pattern library
    • best practices prose – explaining what and why
    • code snippets – examples that you can use
  • Examples of attractive accessible themes
  • How to make your themes accessible
  • How to test that your theme is accessible
  • A list of gotchas for plugins (perhaps an impostor from another page)

Other potential accessibility reference sections – but not specifically theme related:

  • Guide for writing content in an accessible way

Stimulating Phrases

During our sessions we came up with a series of phrases that were worth capturing as they can stimulate work in different directions and underpin our ethos:

  • Take the onus off the user – A user of a WordPress theme should not have to worry about the accessibility of the theme.
  • Accessibility is coming, it is not going away.
  • Checking all themes for accessibility
  • WordPress will be accessible by default
  • An opt-out for theme authors, but themes flagged as not tested
  • This theme has not been checked for accessibility
  • This theme was approved before WP a11y guidelines were published
  • What’s our theme tagging strategy
  • Accessible icons for themes
  • Automated testing vs manual testing
  • The bonus of SEO from doing accessibility
  • Check the accessibility of the underscores theme and Bones
  • Dispel the myths about accessibility
  • An aggressive timeline
  • An outreach programme

Places that need links to accessibility resources

  • Make WordPress Accessible
  • Accessibility
  • Theme Handbook
  • Developer Handbook
  • Theme upload page
  • Training team page(s)

That’s “finished” for a given value of finished. Return

Accessibility Ticket Priorities for 4.1 beta

Now that WordPress 4.1 is into beta, it’s time to tighten the focus on accessibility tickets to the top priorities to get into the 4.1 release. As always, early in the cycle is a great time for general accessibility work, and late is time for polishing new interfaces and tackling small details that can make the whole thing better with minimal impact.

Update, 11/22/2014: 6 issues fixed.
Update, 11/25/2014: 1 issue fixed, one punted for 4.2-early
Update, 12/4/2014: 1 issue fixed
Update, 12/8/2014: 1 issue fixed

New features

New interfaces should be checked immediately, to verify that there aren’t any major issues. In WordPress 4.1, the significant UI changes are Session Manager (found on the user profile page when logged into multiple instances), Site Language (Settings > General), Focus (editor distraction-free-writing). Other changes are more iterative, including changes to focus states and color contrast – on the whole, there are only minor updates to the UI in 4.1.

Twenty Fifteen is also a major addition in 4.1, and has received a lot of feedback already.

Relevant tickets:

  • #30364 – Destroy sessions feedback and valid HTML Fixed.
  • #28599 – Better Visual Focus Indication in Admin Menu

There are currently no other outstanding tickets pertaining to these new features or Twenty Fifteen. Woot!

Iterations to recent features

The Add Media Panel is still a source of enormous complexity with outstanding issues, as is the Customizer. These tickets are JS heavy, for the most part, and could use somebody with a good JS sense to weigh in.

Add Media Panel

  • #29326 – Improve accessibility of edit mode (slated for 4.1 already) Fixed
  • #29371 – Focus keeps jumping to URL field – Closed, replaced with #30512
  • #29455 – Plugin Info modal close button does not announce (just needs commit) Fixed
  • #28864 – Cannot access edit menu options with keyboard inside Image Editor
  • #25103 – Submit buttons on form fields in the Add Media Panel
  • #30348 – Arrow key navigation in Media Grid skips ids Fixed
  • #30390 issue with keyboard/VO accessibility for uploading new images in Safari using the Add Media Panel. Fixed


  • #22237 – Add keyboard shortcuts for collapse/expand, panel-back, and close to the Customizer
  • #28892 – Customizer – Widgets – Feedback for screen reader users when moving widgets/other actions Fixed

Miscellaneous issues

  • #26167 – Plugin activation links need to contain plugin name and the “Plugin” column should be marked as row header
  • #26758 – Edit tags form on submission does not stay at the same page and gets redirected
  • #28873 – JS code for adding bookmarklet Press This hard to access from keyboard
  • #29022 – Screen reader text (and link title) isn’t updated when plugin update count is updated
  • #29958 – Collapse admin menu keyboard accessibility
  • #30010 – Hide admin menu separators from screen readers Fixed
  • #29715 – Remove accesskeys from quick edit and bulk edit

Iterations to front-end output and related functions

  • #21221 – Image title and alt attribute content should be texturized.
  • #30180 – wp_get_attachment_image_src does not return alt or meta.
  • #29808 – Post/paging navigation template tags Fixed
  • #29974 – Focus handle at wrong place when you click reply

I’m specifically targeting easy targets to whittle down the ticket list, to clear space in the report for new issues and some of the long-outstanding major concerns for 4.2. In 4.2, it would be nice to hit some broad issues like the settings pages in general and the usage of anchor vs. buttons across the UI.

This isn’t everything, but it hits a lot of issues that have received work and just need to be finished off.

Design of the on focus admin menu and plugin activation links Test session Nov 10, 2014

This week we discussed two tickets in our weekly test session.

#28599 Better Visual Focus Indication in Admin Menu:
@florianziegler, @afercia and @michaelarestad designed proposals we discussed. @michaelarestad came up with a mockup that needs more contrast but is beautiful.
We will discuss this further with the ticket and on Wednesday at the a11y team meeting (Nov 12). Hopefully some designers can join in to give their opinion.

#26167 Plugin activation links need to contain plugin name and the “Plugin” column should be marked as row header:
There is a new patch, a refresh of the one by @bramd. @arush tested it with a screen reader and it works perfectly.

And from today Slack is also accessible for a screen reader, so @arush could join us in the chat.