massively maintained accessibility: wordpress
TRANSCRIPT
Find these slides
These slides are posted at Slideshare:
http://slideshare.net/[tbd]
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.
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.
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.
Accessibility Needed Involvement
● Today: 326 active tickets
● Needs 2-way conversation
● Needs early involvement.
● People providing patches.
● People with access to manage Trac.
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.
Education for WP Developers
- WordCamp talks
- Articles at make.wordpress.org and
elsewhere
- Code resources
- Online coursework
- Active involvement in Trac tickets
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
Core Developer Buy-in
Has been a total success.
(This doesn’t mean there aren’t differences of
opinion.)
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
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.
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
Looking Forward
Major movements in the future:
- JSON REST API - https://wordpress.org/plugins/json-rest-api/
- Image Flow
Threats and opportunities...
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.
Impact of Choice
- Example: forms- WordPress: no core form builder
- Drupal: oh yeah, we’ve got that.
- Developer choice always overrides core
behavior. Everywhere.
CMSs Produce HTML
Valid HTML is accessible.
JavaScript, CSS, invalid HTML, and
inaccessible content break everything else.
Identifying WordPress Issues.
In the admin:
probably core. Unless it’s a theme or plug-in
settings page...
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...
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’.
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.
Thank you!
Joseph Dolsonhttp://www.joedolson.com/
http://twitter.com/@joedolson