I have read the paper by Chris Law et al., “Programmer-Focused Web[-S]ite Accessibility Evaluations” (abstract), and I don’t think it provides really substantial advice, but at least it has a set of advice to which we will now actually have a published reference. (The article needs serious copy-editing, by the way.)
The authors gripe that accessibility evaluations are all about disabled people rather than programmers, who are the ones who actually end up fixing a lot of the deficiencies. (Not all the deficiencies, of course; they might not write alt texts.) Meanwhile, typical accessibility evaluations snow a programmer under with hundreds of overlong error messages. And of course WAI’s proposed evaluation methods require so much effort that they’re more suited to making the legal case against a war criminal than getting a site redesign out the door.
The authors come up with something they call SERPA (Streamlined Evaluation and Reporting Process for Accessibility). It seems the most important parts are:
- List all the fixes, not WCAG checkpoints. Tell them what to fix, not which piece of documentation requires it.
- Give them only the items that programmers can fix (so indeed, no
alttexts). - Separate easy fixes and hard ones.
Another suggestion, “give evaluation results in a form that programmers can use,” is contained in an amusingly-written paragraph but does not say what that form could be. (Excel spreadsheet? Monospaced fonts on a computer screen, with no antialiasing?)
I think the very most interesting point is to count every instance of the same error as one error. You can have either no entry on a particular error or one entry with n instances. Three hundred missing heading elements are still the same single solitary error. In this respect, one’s esteemed colleague John Allsopp thinks exactly the same way.