- From: Matt May <mattmay@adobe.com>
- Date: Fri, 21 Aug 2009 13:49:04 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- CC: "public-html@w3.org WG" <public-html@w3.org>
On 8/21/09 2:29 PM, "Maciej Stachowiak" <mjs@apple.com> wrote: > I don't think it gives that impression. The guidance on missing alt > for content authors / producers is that they MUST provide some some > best-effort text description via @title or a <figure> <legend>, and > only in the case where image contents are unknown. This text certainly > does not get you off the hook. I don't intend to use this sentence to argue the larger @alt debate. I think the text has shifted somewhat since I raised this objection, but if anything, the image analysis sentence only seems more orphaned. > Indeed, I think it lets authors off the > hook *less* than the WAI's proposed "missing marker" solution. That's not a solution, and it wasn't proposed by WAI-CG. The group merely "(does) not oppose the creation" of such an attribute. > The intent is to let browsers use whatever smarts they have available > in this unfortunate case where the producer of alt cannot describe the > image. Would you be satisfied if it were described in more generic > terms? Yes, preferably if it's clear that the output of this theoretical black box is not to be construed as an equivalent alternative. I would be as or more satisfied if it were left out. I agree with you that "it's ok to do something smart", but I don't think there's any particular need to say anything specific to affirm that here. If the sentence in question were gone, no one would miss it, IMO. > Perhaps a phrase like "describe features of the image" might be better. I still think that's a stretch. > Let me give an example of what I think is feasible with the state of > the art. Check out Google Labs Similar Images: > <http://similar-images.googlelabs.com/>. Using algorithms like this > against a corpus of baseline images labeled with keywords > it should be possible to give a rough > description of the contents of many images. That's far short of > "mak[ing] sense of the image" but also quite a bit more advanced than > OCR. The problem is that all of this data at least appears to be culled not from the image itself, but from its associated metadata (e.g., ironically enough, @alt), and its neighboring content. Now, the first step from that toward what is suggested in the spec is to allow users to upload an image lacking metadata, and receive content that matches it. That's a huge jump. > That is exactly what it's considered - a last-ditch repair attempt. I > believe this is clear in context. I believe the motivation for this > allowance is to align the ATAG2 position that last-ditch repair for > missing alt is best done by the user agent, not the authoring tool. That's not how I read it, and I co-edited ATAG2, so I'm not thinking that bodes well for others. (I'd suggest that ATAG's position has been that last-ditch repair shouldn't be done by the authoring tool at all, since it would be altering the author's intent without the author's interaction. That is, it's better to leave broken content broken and trigger the UA's repair techniques, and evaluation tool failures, than transparently make it look like it's okay.) > I'd like to see some statement explicitly allowing browsers to use > whatever means they have at their disposal to provide textual > information about an image. I think a statement that's more technology- > neutral would be an improvement. For example, there's no explicit > allowance for using EXIF tags, even though those could provide useful > info about many images without the need for science fictional > algorithms. I'm not against saying UAs may use image data or metadata to present more relevant information to users, but then there's really no need for the following bit about users who are blind or are using text-only browsers. Improved support for metadata on images should be beneficial to everyone. - m
Received on Friday, 21 August 2009 20:49:52 UTC