In Attendance:

  • Aaron Jorbin
  • Emil Uzelac
  • Kevinjohn
  • Amy Hendrix
  • Michael Fields
  • Dave Martin
  • Jake Goldman
  • Isaac Keyet
  • George Stephanis (note taker)

Discussion Notes

Kevinjohn brought up the initial concern that, in the EU, some groups can’t use WordPress, as it hasn’t met some accessibility requirements for a few releases now — but we’re close.  Have to meet AAA standards for EU.

How’s the back-end for accessibility? Jorbin brought up that he, Nacin, and Koop sat down with a blind user and did accessibility testing of post screen — everything was properly set up except for the post box itself.

(aside: question of if we should / how we could make it easier for front-end users to be accessible is nipped in the bud for later discussion)

Amy Hendrix brought up the question of new accessibility tests for themes — which is a work in Progress

What is the accessibility group?

Aaron Jorbin pointed out that we should get accessibility experts more involved in WordPress. By bringing the accessibility community into the WordPress community, we all benefit.

One of the challenges is that it is hard for much of the core team to test accessibility patches do to them not having copies of accessible technology software. A good deal of the software is commercial (or only runs on one operating system) and few people have copies to test patches against.

(aside: someone pointed out that it would be nice to automate patch applying by generating trunk installs on the fly and applying patches to them, to enable less-technically-minded people to contribute to testing.  Perhaps on or similar?)

We need to migrate from being reactionary to proactive!  While there are a couple patches for 3.5, we may need a set of guidelines for a11y standards, the same way that we have php and css guidelines.

It would be very useful to add a high-contrast theme for the admin UI.

We also need to emphasize the reasons to focus on accessibility — better SEO results and marketing, for one. The W3C has an article on the web accessibility business case.

(aside: could we possibly include an API for toggling high contrast mode on or off?)

It would be nice if TwentyThirteen was designed accessible as a number one priority, but how do we get there? We need someone to take responsibility.

Isaac Keyet mentions that mobile apps are mostly compliant, but it’s more dependent on the platform that you’re on.

Drupal contacted the governments and asked what they needed to do to become fully compliant. We need to get data / feedback that lists what we have already, and what we need to be properly up to spec.

Standards — which ones should we focus on? There are multiple options.

Checklists to compare patches against would be really helpful! Accessibility is much more than that, but it’s a tool that could help devs not as familiar with Accessibility. Not a solution.

Should we add a `not-accessible` or `needs-accessibility` tag in trac? These could make it easier and puts accessibility on the same level as UI or UX. It’s not a feature, it’s a core asset.

We need more accessibility talks at WordCamps … bring accessibility into the popular mindset.


  • Add a section to the Handbook.
  • Add in some requirements for patches that they be tested against accessibility guidelines.
  • Need someone to take ownership for things going forward.
  • Page on .org talking about what certifications we meet.
  • Challenge TwentyThirteen to be designed with accessibility as it’s number one Priority.

Action Item:

We want to add which will be a one stop shop for successes we’re having and ways people can get involved. This is partially inspired by The Drupal Accessibility Page.

#a11y, #accessibility, #eu, #standards