Re: Discussion on Change Proposal for ISSUE-66

On Jan 21, 2010, at 8:16 PM, Matt May wrote:

> 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

This seems to be focused on repair techniques for authoring or evaluation tools, where they find a problem and make or suggest changes to the markup. It doesn't seem relevant to this situation.

> 
> Not to mention a W3C Recommendation which contains specific guidance on handling missing @alt:
> 
> http://www.w3.org/TR/UAAG10/

I see the following in UAAG: <http://www.w3.org/TR/UAAG10/guidelines.html#tech-missing-alt>

Is that what you had in mind? Two thoughts on this:

1) This seems to not only allow but require UAs to repair missing content. Therefore, I think HTML5 should at least allow repair of some form. We could either make this an explicit MAY-level requirement, or just let it be implicit that repair is allowed. I think it's probably better to be explicit to remove room for doubt.

2) The suggestions cited there (using the URL, content type, or element type) are potentially useful, but the idea of using OCR is not mentioned at all. Perhaps OCR was less practical when UAAG was first published. That being said, I think this suggests an update to UAAG rather than different advice in the spec. What's the best way to provide feedback on UAAG?

> 
> 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 think it would be good to reference UAAG in the same way as WCAG.

> 
>> 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.

I think our minimum level of consideration should to be to ensure that things *required* by UAAG are at least *allowed* by HTML5.x. In this case, I think we can satisfy that goal by making sure that repair for missing alt is allowed in HTML5, without going into too much detail about what techniques could be used. What do you think?

Regards,
Maciej

Received on Friday, 22 January 2010 04:35:48 UTC