As mentioned in the previous posting on Web Design Pitfalls, a lot of them could be lumped under the accessibility umbrella. That was a nice segue to this post which is all about accessibility and why it should be tested for.

First, the why? It used to be that if you designed your product to be accessible, then you were just doing so to be a good citizen and to reach out to a larger potential audience (which can great for creation of brand loyalty, I can’t find the exact blog entry but I’m pretty sure it was by Seth Godin). Now however, there is an even larger reason to be accessible. That reason is Section 508 of the United States Rehabilitation Act which states:

When developing, procuring, maintaining, or using electronic and information technology, each Federal department or agency, including the United States Postal Service, shall ensure, unless an undue burden would be imposed on the department or agency, that the electronic and information technology allows, regardless of the type of medium of the technology

Given the context that the US government is the largest procurer of software and software services in the world, this is huge. Naturally, the devil is in the details and the phrase unless an undue burden would be imposed seems like the window for weasling out of this, but if your product is in a contract bid against one that is not, it appears that they are required to weigh in your favour. This advantage I think is one that should be pursued aggressively.

Just like L10n though, embarking on accessibilizing (yes, I am making up words here) your product is a major undertaking both in physical work and (re)training your developers on how to work. Unless every person who commits code, and develops requirements has accessibility in mind when doing their day-to-day work you will constantly have fire accessibility fires instead of preventing them entirely. The good news however is that the Rehabilitation Act has been around for awhile now so there is lots of information available on how to interpret it and suggested methods to implementing it. The best one I have found is the WebAIM Section 508 Checklist. Here is a direct copy/paste from it to illustrate it’s comprehensiveness.

SEC. 508 STANDARD PASS FAIL
(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. The user has control over the timing of content changes. The user is required to react quickly, within limited time restraints.

Clear and to the point.

Some other Section 508 resources I have tucked away:

Oh, and a sigh of relief for some readers; you might notice that applications dealing with National Security are exempt form the provisions contained in the Act, so certain Authentication and Authorization product families are immune from this. For now.