We had a great meeting to discuss the future of theme accessibility. You can review the complete transcript of the chat in Slack.
We discussed many of the aspects of what it will take to make accessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) a requirement for themes – it’s a long process, but we agreed that this is possible. We started by discussing where the most appropriate place is to publish our kick off article, which is going to give three examples of areas where theme authors can improve the accessibility of their themes immediately. It will be published either on Make/Themes or here on Make/Accessibility, followed by an extensive effort to share in the community.
Next we discussed the fledgling repository for WordPress-specific code examples for accessibility. The repository already exists at GitHub, so it’s just a matter of writing code and organizing it. David Kennedy will take the lead on developing that resource.
Moving on, we discussed how to organize theme accessibility information and advice into the Theme handbook structure. We concluded that a conversation about how that fits in is needed, and I’ll have that with Tammie Lister before we decide exactly what those documents will be, as well as moving the existing Accessibility guidelines around in the theme reviewer’s handbook.
Morten Rand-Hendriksen reviewed the original plan sketched out at the community summit to give people who weren’t there a basic understanding of the conversation.
This brought up a conversation about future handling of the ‘accessibility-ready’ tag and how we should share information in the WordPress theme repository about whether a theme has been reviewed for accessibility. Right now, it’s fairly moot given the small number of themes that have been reviewed, but by the time accessibility becomes a requirement, it will be important to start labeling, to take the onus off end-users to discover whether their theme will allow them to meet their country’s legal requirements for accessibility.
Both these issues will need to be proposed to the theme review team, so we’ll be working on writing a precise proposal that can be taken to that team and be voted on. The important thing with the proposal is clarity.
Finally, we discussed theme reviewer training. I’ll set up a date with Tammie to work through the process with her, but will ultimately need to do something that’s less one-on-one, either through a detailed written document or a video training resource. This training process would be greatly helped by having the code repository fleshed out, so that those code examples are available to reviewers and theme developers.
#accessibility-ready
