- From: Matt May <mattmay@adobe.com>
- Date: Thu, 21 Jan 2010 20:16:43 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Shelley Powers <shelley.just@gmail.com>, Jonas Sicking <jonas@sicking.cc>, HTML WG <public-html@w3.org>
On Jan 21, 2010, at 6:55 PM, Maciej Stachowiak wrote: > I can also see Ian's point that we should allow and encourage UAs and ATs to do whatever they can in the face of content that is not accessible. And it seems to me there are sources of additional information that are completely within the reach of mainstream technology. Examples: (a) read the filename, but only if it appears to be human-readable, not a stream of random letters and numbers; (b) perform OCR on the image, OCR these days is readily available and highly accurate; (c) provide the contents of relevant EXIF tags. When it comes to repair advice, we've been there before, many times. There's an old WD that covers repair techniques: http://www.w3.org/TR/AERT Not to mention a W3C Recommendation which contains specific guidance on handling missing @alt: http://www.w3.org/TR/UAAG10/ Rather than reinvent accessibility guidance when it already exists in a W3C Rec created specifically for this purpose, I would suggest referencing that standard directly where user agent accessibility advice is called for. I note that UAAG has not been referenced in the spec to date. > I am hoping we can find a happy middle ground by giving a general allowance for use of more information when alternative text is missing, or in general in the face of broken content, without overselling its capabilities. I think important considerations for that are: (1) don't get overly specific about the type of techniques to be used, or if examples are given, make sure they are squarely within the mainstream of current technology; (2) make very clear that these are intended to be emergency repair techniques, not something for authors to rely on. I'm all for adding informative text on accessibility where it is relevant and helpful to the spec, and especially where it meets your requirements. To that end, I humbly suggest that anyone who does so, read the corresponding sections of UAAG 1.0 (and, for that matter, ATAG 1.0 and/or 2.0) for existing recommendations; cite it, where it's useful; then, in cases where there is disagreement, explain why deviating from that guidance is necessary. Despite the fact that UAAG is 7 years old now, it still covers lots of what is being discussed in HTML5. It's a must-read. 5 stars out of 5. - m
Received on Friday, 22 January 2010 04:17:16 UTC