Patrick raises some good points in his post on Accessify about this article. I tried to comment but seeing as I got an error I thought I would add the comments here instead.
Patrick says: “I don’t quite follow why the form (All non-text content has a text alternative that presents equivalent information, except for the situations listed below) that’s now in the latest working draft is supposed to be bad.”
It’s actually the four sub-sections that are the problem - which didn’t make it into the article because it made the page too long! These four sub-sections are:
1. Controls-Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (See also Guideline 4.1.)
2. Media, Test, Sensory: If non-text content is multimedia , live audio-only or live video-only content, a test or exercise that must be presented in non-text format , or primarily intended to create a specific sensory experience , then text alternatives at least identify the non-text content with a descriptive text label. (For multimedia, see also Guideline 1.2.)
3. CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided and alternative forms in different modalities are provided to accommodate different disabilities.
4. Decoration, Formatting, Invisible: If non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, then it is implemented such that it can be ignored by assistive technology.
With regards to your comment on the use of subjective words such as “inconsistent”, “predictable” etc in WCAG2 - it really comes down to the definition of “testability”. In my time on the Working Group it appeared to me that testability was applied quite strictly to certain checkpoints - such as the clear and simple language checkpoint - whereas it was more lax on other checkpoints - such as alt attributes. One could argue that eight out of ten people couldn’t agree on whether the result from activating a search is “predictable” - will it provide ten search results? twenty? Will it include summary information? etc. If we are going to allow subjective terms like “predictable” then what is the problem with other subjective terms like “clear” and “simple”?
*The WCAG Samurai Errata*
Another area of confusion with WCAG2 (once again due to testability) is that it increases the complexity of the success criteria. Because WCAG2 is technology-neutral, the guidelines have to be testable in a technology-neutral way. Therefore a simple checkpoint in WCAG1 like “Title each frame to facilitate frame identification and navigation” becomes “The destination of each programmatic reference to another delivery unit is identified through words or phrases that either occur in text or can be programmatically determined.” It’s not until you drill down to the techniques that it becomes clear that this success criterion is actually about frames at all. The WCAG Samurai Errata is certainly clearer when it comes to frames (it says not to use them!)
In my conclusion I wasn’t trying to say that the WCAG Samurai Errata are a better set of guidelines - I was attempting to say that if there are easier to use guidelines available then developers will turn to them, instead of WCAG2. I see that being a real problem in the accessibility community - developers choosing one set of guidelines while Government and management choose another.
I am really hoping that the WCAG Samurai address issues faced by people with cognitive disabilities. I see it as a way to really set the two guidelines apart. I believe the Working Group is wrong to say there isn’t much research in the area- a set of guidelines can be developed.
When it comes to testability I think it was a noble aim. I think it would be fantastic if every accessibility requirement could be defined in a testable way. However, for those requirements that can’t (eg. clear and simple language), the requirement should not be excluded from WCAG2. At the end of the day, if it helps people with disabilities use the web then it should be included in the accessibility guidelines - whether they be WCAG2 or the WCAG Samurai Errata.