Recently, I’ve been thinking about the crucial nature of timing in what I do. Like everything, when you engage on a particular step can have a profound impact on what you can accomplish.

In any web project, engaging on web accessibility from the beginning can make the difference between a nominal percentage of the budget dedicated to ensuring accessibility and massive budget bloat caused by the need for extensive review of complex systems that gave no thought to the subject at any point in the process.

Working on accessibility with WordPress, however, timing has to do with what we test, and when.

WordPress 3.9 launched yesterday. This was the second release of WordPress where I feel that the WordPress Accessibility Team was able to have an impact: we’re finally getting things sorted out. There were a lot of potential accessibility issues avoided and old issues fixed in this release. But we could have done better; and the main reason we didn’t was timing.

What did we do wrong?

We wasted time early in the cycle doing testing on WordPress 3.8. I’m not assigning any blame on this; I recommended and encouraged it, but by a couple months ago, I was realizing that it was a bad decision.

The problem was that we took too long – testing WordPress 3.8 might have been valuable, if we’d been able to get to the whole application in a week or two, so that we could generate patches immediately, and move them into 3.9 before it started to change too much. Unfortunately, that was an unrealistic target.

You always waste time if you’re testing something that isn’t the project being worked on. And as soon as one version of WordPress (or any other piece of software) is released, it’s become a fixed point in time: it’s not the project being worked on — it’s just what the current project started from.

Working on WordPress trunk means that you’re working on a moving target; but working on a released version means you’re working inside a coffin. It doesn’t matter what you learn; you’ve learned nothing more than how things used to be.

How can we move forward, better?

Other than dealing with accessibility support requests, so that we can make sure we’re dealing with them for point releases or in the next version, we need to forget that past versions exist as soon as they’re released. We need to be forward thinking: instead of dwelling on what is currently wrong, focus on where we’re going next.

Remember: the first release of WordPress Next is fundamentally identical to WordPress Last. But as long as we work on WordPress WordPress Last, we’re losing ground on what’s going on now.

That’s my mission for the future of WordPress accessibility: get focused on problems at the right time, and avoid wasted energy.

So, WordPress 3.9 — you were released yesterday. Hello…and Goodbye!