As a consultant, I have the privilege of getting a bird’s eye view at how different clients manage (or just claim to manage) good accessibility governance in their organizations.  “IT Governance” is a hot topic these days and it makes particular sense when dealing with the craziness of the internet.  Some of my clients have between 500 and 1,000 web domains that they need to keep accessible.  Among those hundreds of domains, some might use elaborate content management systems (homebrewed or commercial products), others are heavy on Flash and AJAX, and some are just plain old HTML and CSS.

Sure, automated tools can help (and I can think of one from a company in New Hampshire that’s better than all the rest), but the real solution to good governance is good citizenship.  And the key to good citizenship is making sure citizens (here, developers and testers) have a clear understanding about why to do things and how to do things.

I’m not going to get into the why part here, other than to say that it’s vital to develop a good understanding among testers and developers about why accessibility matters.  I have some strong feelings and powerful tools for creating buy-in and support for the why side of the equation, but that’s for another series of posts.  What’s got me buzzing recently is the how part.  So I’m going to devote four posts to the seemingly simple topic of how accessibility knowledge can be governed simply and easily.

I’m buzzed about this topic because so few organizations get it right from the start.  They struggle and make really costly mistakes.  They might even try extremely complex methodologies and wonder why they can’t succeed like the million-dollar-an-hour consultant told them they would.  Then, they take a deep breath, pick up the phone, and ask for some basic, common sense help.  So I’ll just lay my cards out on the table and show you how I do it.  My only caveat: if you’re one of those million-dollar-an-hour consultants, read no further.

For me, the how part of the equation comes down to just two key tools that need to mature and work together:

1. excellent requirements (including tools for filtering those requirements)
2. a version-controlled knowledgebase for augmenting those requirements

Why these two tools more than any others?  Because an excellent set of requirements tells developers and testers exactly what they have to do and when they have to do it.  Simplicity is best here, but it still has to be thorough.  A set of requirements also needs a filtering tool, however, because otherwise a list of enterprise-wide requirements will seem unbelievably daunting (this is actually the frustration I have with WCAG 2.0 that is leading me to create my constantly-delayed WCAG 2.0 flowchart and questionnaire).  A good filtering tool gets rid of the stuff that isn’t applicable to a project and gets developers and testers focusing only on the stuff that counts.  A good filtering tool is also essential from a psychological perspective— nothing turns people off to a thick set of requirements more quickly than just “tossing them over the fence” without any guidance on their specific applicability.  My next post in this series will talk about how to develop excellent accessibility requirements and filtering tools.

But a great set of requirements is just the beginning.  Questions always come up about how to meet particular requirements using particular technologies or in particular circumstances.  The second key to the how part is making sure that the answers to those questions are consistent and easily available to everyone.  They also need to be “tied” or “traced back” to the requirements that they relate to.  It’s also okay for the answers to change over time— as long as the answers are version-controlled so people understand the history and why the answer changed.  My third post in this series will talk about how to tie this information together and will hopefully give you some ideas for how to create your own knowledgebase in your organization and fire that nasty million-dollar-an-hour consultant.

My fourth (and last) post in the series will talk about how the pieces all fit together and create great web governance.  I promise that the jargon will be simple— something that million-dollar-an-hour consultant could never give you.

As an aside, I’ve also been thinking about why this is such an important topic to me recently, other than the fact that I see it messed up time and again.  I think there are really two additional reasons why I’m passionate about it.  First, anyone who knows me or who has worked with me knows that I’m a process junkie.  I can still remember joining the Justice Department back in 1992 and developing a paralegal-allocation tool so my fellow attorneys and I wouldn’t squabble over getting paralegal help on our ADA cases.  Second, abstracting a bit, tracing requirements isn’t very different at all from doing legal research into regulations, statutes, and case law.  Attorneys have pretty simple and refined tools— and good requirements tools aren’t all that different.  I get excited because I get to use my legal background in a very different way.