On Mar 18, 2010, at 2:58 PM, David Singer wrote:
It does seem that saying that CAPTCHAs are bad, don't use them, is pointless, like pushing on a piece of string; web site designers don't include them for fun, and they would use better techniques if they were available.
Well, yes and no. I think there's been a self-perpetuation to CAPTCHA: sites use it because other sites (usually with much larger attack surfaces) use it. I think that in many cases, things like server-side heuristics would provide superior protection, without raising accessibility barriers. But I agree that HTML5 is not the place to legislate CAPTCHA out of existence.
I believe that it is a unique enough use case, and is used frequently enough that a case could be made for a "captcha" role on img. That would give UAs and assistive technologies a chance to call internal or cloud-based CAPTCHA solving systems like Webvisum, and validation/eval tools to mark them as an accessibility issue.
It also seems that removing the example from HTML5 is silly, because we know they happen, and we ought to provide guidance. That guidance should probably be both:
a) the 'local to HTML5 guidance' on how to identify/label/title/etc. a CAPTCHA
b) the 'general guidance' pointers to WCAG or the previously cited note on CAPTCHAs and their general issues.
Agreed.
I assume the WCAG guidelines say that, if you do use them, try to provide at least a couple of alternatives using different modalities (e.g. standard visual one, and an 'answer this topical or logical question' one, which is accessible to screen readers etc.)
Basically, yes.
"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 of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities."
http://www.w3.org/TR/WCAG20/#text-equiv
-
m