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.
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.
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...
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.
Up to this point, while individuals worked on accessible themes or on reporting and patching accessibility issues, there was no organized efforts to build accessible interfaces, provide education, or do user testing.
After an enormous amount of feedback in May, the accessibility team fell largely quiet. Mel Pedley, the team leader, posts occasionally into silence.
OK, it was a slow start. But what wasn’t happening? Mel Pedley had been a steadfast voice for WordPress accessibility for years. But there was a lack of other people working both in WordPress and accessibility. We had leadership; but not involvement.
Talk about how the involvement of accessibility experts was valuable, but the names weren’t recognized by the WP community.
Talk about how the involvement of accessibility experts was valuable, but the names weren’t recognized by the WP community.
What’s an active ticket? Any ticket with activity within the last 2 weeks. The actual number of open tickets? Let’s not go there.
It’s a waste of everybody’s time to look at the list of all accessibility issues and say “fix these”. It’s a waste of time to raise an issue like “WordPress doesn’t meet Section 508 guidelines”.
History includes tickets like “Media modal not accessible” and
(And those are just the ones the team can review!)
Video URL: https://www.youtube.com/watch?v=0GplRDFSGL4