The process of integrating accessibility into the core WordPress development process has been challenging, but also rewarding. This presentation talks about the path we've taken in building the process, what steps we take to handle accessibility in WordPress, and where we're going in the future.

1. Massively
Maintained
Accessibility
The WordPress process

2. Find these slides
These slides are posted at Slideshare:
http://slideshare.net/[tbd]

3. Let’s start with a little time travel.
March, 2011:
- Make.WordPress.org/accessibility is created.
May, 2011:
- First request for accessibility comments:
request for comments on 3.2 and Twenty
Eleven.

4. Let’s start with a little time travel.
May-November, 2011:
...

5. Building an organization
- Leadership
- Involvement
- Process

6. The WordPress Process
● Propose enhancement, bug fix, or feature
plugin.
● Get buy-in from other developers.
● Provide feedback on issues.
● Stuff happens...
● Get committed to core.

7. The WordPress Process
● Release Lead: sets priorities, guides
development.
● Getting the release lead involved is crucial.
Big thanks for Drew Jaynes, release lead on
WordPress 4.2, for his focus on accessibility.

8. Accessibility Needed Involvement
● Today: 326 active tickets
● Needs 2-way conversation
● Needs early involvement.
● People providing patches.
● People with access to manage Trac.

9. How many contributors are there?
By release:
3.8: 188 3.9: 267 4.0: 275 4.1: 283
Hundreds of people and thousands of patches
= many opportunities to introduce
accessibility issues... or solutions.

10. Education for WP Developers
- WordCamp talks
- Articles at make.wordpress.org and
elsewhere
- Code resources
- Online coursework
- Active involvement in Trac tickets

11. Effective Strategies
- Specificity: not “WordPress does not meet
Section 508 guidelines”.
https://core.trac.wordpress.org/ticket/29955
- Prioritization:
https://make.wordpress.org/core/2015/02/23/
this-week-in-4-2-february-23-march-1/
- Follow up

12. Core Developer Buy-in
Has been a total success.
(This doesn’t mean there aren’t differences of
opinion.)

13. What’s happening now?
- Testing group managed by Rian Rietveld
- https://make.wordpress.org/accessibility/testing/
- 2x per release priority lists of issues.
- Advance requests for consultation from core
development, UX team and feature plugins.
- WordPress accessibility pattern library
- Theme accessibility testing and training

14. Long term strategy
● Slow but steady
● Three releases per year with individual
iterations.
● Create solution libraries (#31368: Let WP
Speak, WP pattern library) and educate
developers.

15. Backwards Compatibiliey
- API compatibility for 36,000 plugins and
3,000 themes has deep ramifications:
- Settings API
- Legacy widgets and functions
- Use of screen-reader-text classes
- Form behaviors
- Admin headings and HTML structure

16. Looking Forward
Major movements in the future:
- JSON REST API
- https://wordpress.org/plugins/json-rest-api/
- Image Flow
Threats and opportunities...

17. What’s the most accessible CMS?
Drupal

18. What’s the most accessible CMS?
Does this mean that Drupal web sites are
accessible and WordPress web sites aren't?
No. On both counts.

19. Impact of Choice
- Example: forms
- WordPress: no core form builder
- Drupal: oh yeah, we’ve got that.
- Developer choice always overrides core
behavior. Everywhere.

20. CMSs Produce HTML
Valid HTML is accessible.
JavaScript, CSS, invalid HTML, and
inaccessible content break everything else.

21. Identifying WordPress Issues
Core.
Plug-in.
Theme.
Hey. Who screwed up this site?

22. Identifying WordPress Issues.
In the admin:
probably core. Unless it’s a theme or plug-in
settings page...

23. Identifying WordPress issues
On the front end?
- main menu or post content? Probably
theme.
- In a contact form, special feature like a
calendar or eCommerce service, it’s a plug-
in...

24. Identifying WordPress Issues.
...unless it’s a commercial theme.
WordPress.org themes have to follow rules:
https://make.wordpress.org/themes/handbook/review/
Commercial themes have their own ‘rules’.

25. Reporting WordPress Issues.
Core issues should be reported here:
https://core.trac.wordpress.org/newticket
Before reporting anything, check with all plug-
ins disabled and the default theme enabled.

26. Thank you!
Joseph Dolson
http://www.joedolson.com/
joe@joedolson.com
http://twitter.com/@joedolson