The WordPress WayAccessibility & Backwards Compatibility

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

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

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?

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

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

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.

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?

Case Study: Changing the Comment form

- 4.4: moved the comment textarea to the top of the form.

- Impact on themes?

- Impact on plugins?

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?

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

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

What else?

- Internationalization & labeling

- Accretion of new options without discarding the old

- Need to keep up with everything new

Speaking of new stuff...

- Anybody heard of Calypso?

- What about that REST API?

- Where do developers want to focus?

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.

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.

Please Help!

https://make.wordpress.org/accessibility/