- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 21 Jan 2010 18:44:29 -0800
- To: John Foliot <jfoliot@stanford.edu>
- Cc: 'Matt May' <mattmay@adobe.com>, 'HTML WG' <public-html@w3.org>, public-html-a11y@w3.org
On Jan 21, 2010, at 6:35 PM, John Foliot wrote: > Maciej Stachowiak wrote: >> >> 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. > > However Maciej, none of these can determine author intent, and at the end > of the day if a 'page' has an image inserted using the <img> element, then > it is there for a reason, and so that 'reason' needs to be expressed as > part of the alternative text - there is a cognitive requirement as well > that technology alone cannot deliver. I totally agree. The question is not at all about whether proper alternative text is required. It's just about repair techniques when alternative text is missing. That's why I suggested that the spec should be clear that any info gathered is an emergency repair technique Let's say you actually have a page with an <img> that's missing alt text, and a blind user browses to it using their favorite AT+browser combo of choice. Are you saying you wouldn't want the browser or assistive technology to use the above techniques? >> 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. > > Let's turn this on its head for sake of discussion: would those who > believe this is a viable point of view feel the same way if the following > code: > > <img src="[broken path]" height="350" width="600" alt="Ford"> (and > yes, this is deliberately bad alt text, but not uncommon in the wild) > > ...allowed UA's to invoke their magic heuristic powers to seek out another > image of "Ford" that was about 350 X 600 pixels (from say Google's > gadzillions of indexed images), and replaced the 'missing image' with a > replacement image; do you think that the 'industry' and authors in > particular would find that an acceptable solution? In many ways, that is > what is being suggested here; I mean, is substituting this 'ford.jpg' > image: > > http://www.myrddin.it/merlino/mimg/ford.jpg > > ...for this 'ford.jpg' image: > > http://www.insidesocal.com/outinhollywood/ford.jpg > > ...sufficient or appropriate? After all, they are both pictures of Ford... The correct behavior in this case would be to show the alt text ("Ford") instead of the image, not find another image. I believe that is in fact what the spec requires. But when you are in the opposite case (image present, but alt text is missing), you can't just show a blind user the image. That's kind of the point, right? So the analogy is not reversible. > > When all is said and done, no technology today (or the foreseeable future) > can read minds, and so no amount of heuristic analysis can substitute for > author supplied alt text that delivers author intent. Nobody is saying "substitute for". The question is just whether repair techniques are allowed in the face of broken content. I ask you again: are you saying that emergency repair techniques by the UA or AT should be explicitly banned? Note that this would make *all* existing AT noncompliant. (The most common current emergency repair for missing alt is to read the filename.) > >> 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 think any statement that suggests futuristic magic as a potential > technical possibility inside a technical specification and standard is > wrong, and should be avoided. I believe what I suggested was exactly the opposite of that. Regards, Maciej
Received on Friday, 22 January 2010 02:45:04 UTC