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!
_Redd
Gotcha! Thank you, Joe! 🙂
Joe Dolson
Well, I’m not saying that we should forget the previous version; but we do need to move focus away from it in our working process.
From a learning perspective, there’s no reason to let go of any past issue; the shape of what you can learn is still the same, but for moving forward, it needs to be future-forward.
E.g., studying a past ticket is great for knowing why a decision was made, what style of solution is preferred, and the history of the arguments on the subject – but when it comes to addressing the issue, the focus need to be on where we are now, with a knowledge of the past.
_Redd
Joe, I am in exceedingly strong agreement with this (yet another) excellent post of yours, with one caveat:
When we do with WordPress accessibility really involves two audiences, not one. The “WordPress” audience, and the “Accessibility” audience. Because teaching about, and learning about, accessibility is such a long and difficult process, I don’t think we can afford to lose “sight” of any lessons learned from the past–“WordPress Last”–as you put it. We are all standing on the shoulders of the work of those before us, and we need those lessons learned from the past to move forward.
Although I too, have dropped any work on 3.9 already, (of what little work I could accomplish on it) and have started exploring trunk-I hope we can keep the history of our lessons learned visible, public–and active– so that the knowledge is passed on. I, for one, still read tickets and fixes for some of the older problems to learn how to fix the new ones. It takes a lot of digging, but if we can keep the solutions public, and in sight, I think it would be a tremendous teaching/learning tool for those who want to get involved.
Thank you, thank you, thank you, for everything you do.
WordPress is definitely MORE better, powerful, accessible, inclusive– because of you.