A progress report on the changes in WordPress accessibility over the last year and a conversation on how the dedication to backwards compatibility makes some of the future changes problems which will be long and slow to solve.

1. The WordPress Way
Accessibility & Backwards Compatibility

2. Year in Review
- 4.2: JavaScript method wp.a11y.speak() to generate and announce JS
updates in an ARIA Live region
- 4.3: Made H1 top level heading on admin screens; fixes to list tables;
inproved :focus styles and states
- 4.4: Release of Twenty Sixteen; updated the admin headings hierarchy
- 4.5: review of color contrast; review of content-bearing title attributes

3. Year in Review
- 4.2: 44 accessibility tickets resolved.
- 4.3: 90 accessibility tickets resolved
- 4.4: 76 accessibility tickets resolved.
- 4.5: 62 accessibility tickets resolved.
Total: 272 accessibility-related tickets resolved since WordPress 4.1

4. Big areas still needing work
- The "List Table" structure used for posts
- The Settings API
- Color Contrast
- The media management UI
- Hidden content: title attributes, anyone?

5. Backwards Compatibility
What's a 1% problem on 25% of the web?
- Estimated sites on the internet: 1 billion. (1)
- Conservative estimate: 125 million active web sites on WordPress
- 1% = 1,250,000 sites.
1. http://www.livescience.com/54094-how-big-is-the-internet.html

6. What Backwards Compatibility Means
...Though typically a “major” version means you can break backwards
compatibility (and indeed, it normally means that you have), WordPress
strives to never break backwards compatibility. It’s one of our most
important philosophies, and makes updates much easier on users and
developers alike.
https://make.wordpress.org/core/handbook/about/release-cycle/version-numbering/, March 2016

7. What Backwards Compatibility Means
Normal expectations:
- Your theme should not break
- Your plugins should continue to work
- Your hosting service should not need to
make any changes to run the new version.
WordPress Practices:
- Your theme should not change
- Plug-ins should not need to update or
adapt to new code
- Your update should be a seamless
experience.

8. How does this affect developers?
1) Does this change affect any known code? How much?
2) What happens if the code is not updated?
3) How difficult is it to update the code?
4) Can the change be broken into stages across multiple releases?

9. Case Study: Changing the Comment form
- 4.4: moved the comment textarea to the top of the form.
- Impact on themes?
- Impact on plugins?

10. Front-end vs. Back-end
- Who is impacted by the change?
- Who is able to fix any problems caused?
- What will be the public perception of the change?

11. Let's talk Technical Debt
- The "List Table" structure used for posts
- Used in dozens of contexts in the admin
- Modified or used by thousands of plug-ins

12. But that's not so bad, compared to...
- The Settings API & WordPress Admin Settings filters
- Used by 10s of thousands of plug-ins
- Requires the plug-in or theme developer to author most or all of the
HTML for structuring the inputs

13. What else?
- Internationalization & labeling
- Accretion of new options without discarding the old
- Need to keep up with everything new

14. Speaking of new stuff...
- Anybody heard of Calypso?
- What about that REST API?
- Where do developers want to focus?

15. Lofty Goals
- Committed to meeting WCAG 2.0 Level AA in future development.
- Change won't be overnight, or even over-decade.
- High expectations for new code so we can avoid future problems means
slower development.

16. Takeaways
- The "low hanging fruit" is getting harder to find.
- Some things that seem low hanging...aren't.
- The REST API opens the door to a whole set of new challenges.

17. Please Help!
https://make.wordpress.org/accessibility/