- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 09 Mar 2010 15:43:41 -0800
- To: Matt May <mattmay@adobe.com>
- Cc: Ian Hickson <ian@hixie.ch>, "public-html@w3.org" <public-html@w3.org>
Ian, are you willing to make the revision Matt suggests? Matt, thanks for being flexible about the range of solutions. Regards, Maciej On Mar 9, 2010, at 2:52 PM, Matt May wrote: > I'm willing to accept this change proposal. It covers what can be done > to images in greater detail, without making it sound like good-enough > repair for missing alt. > > One issue I have, though, is that many of the features mentioned are > more likely to be cloud services than they are to be embedded in a > browser. If the CP can make it clearer that these could be either > native features of the browser, links to services running in the > cloud, or assistive technologies that extend the browsing experience, > I would fully support this proposal and withdraw my own. > > - > m > > On Mar 9, 2010, at 4:46 AM, "Ian Hickson" <ian@hixie.ch> wrote: > >> >> SUMMARY >> >> The spec is very vague about what image analysis techniques could be >> applied to images. This change proposal suggests including more >> detail >> about possible techniques. >> >> >> RATIONALE >> >> Currently the <img> element section mentions that UAs "may also apply >> heuristics to help the user make use of the image when the user is >> unable >> to see it", but the only suggested heuristic is OCR. >> >> In practice, there are a host of other heuristics that could help a >> user >> make sense of an image, and they might be useful even to users who >> _can_ >> see the image. We do all users a disservice by not being more >> explicit >> here. Being explicit could encourage significant competition amongst >> user >> agents, leading to a much better user experience for everyone. >> >> Since these heuristics are in many cases already implemented and >> shipping, >> sometimes in multiple products from multiple vendors, and since >> recent >> advances in image recognition techniques have been fast and furious, >> it >> seems reasonable to mention these techniques as real possibilities. >> >> >> DETAILS >> >> Strike "when the user is unable to see it". Instead, start a new >> sentence >> before the "e.g", which says "This would be especially useful to >> users who >> cannot see the image", and add the following after the "e.g." >> clauses, in >> a separate clause: "but it could also be useful to users who _can_ >> see the >> image, but might not fully understand or recognise it". >> >> Move "optical character recognition (OCR) of text found within the >> image" >> to be the first bullet of a bulleted list, and add the following >> additional points: >> >> * Facial recognition in photographs, especially facial recognition >> of >> notable individuals or of individuals in the user's social >> network. >> >> * Product or brand recognition in photographs or logos. >> >> * Barcode recognition of any embedded barcodes. >> >> * Bitmap to vector analysis for diagrams, allowing images to be >> further analysed in specialised tools. >> >> * Data extraction for graphs, allowing data to be reconstructed from >> bar charts, pie charts, and the like, or allowing regression lines >> to be fitted to x,y plots. >> >> * Landmark recognition for photographs. >> >> * 3D reconstruction of scenes based on multiple images, allowing a >> set >> of images to be taken together and explored in context. >> >> >> IMPACT >> >> POSITIVE EFFECTS >> >> Adding such text could lead to a renewed level of competition in >> browsers >> as they find the best ways to expose such tools to users. >> >> Such competition would inevitably lead to improved accessibility >> across >> the board, as many of these analysis techniques could provide users >> with >> anything from a basic hint of the image's contents to fully- >> interactive >> reconstructions of the image in more accessible forms (especially in >> the >> case of text-in-image or graphs). >> >> NEGATIVE EFFECTS >> >> Makes the spec longer. >> >> CONFORMANCE CLASS CHANGES >> >> None. >> >> RISKS >> >> It is suggested that mentioning that user agents might be able to >> repair >> non-conforming pages could make authors less likely to write >> conforming >> pages, though it is not clear why this would apply here and not in >> the >> many other parts of the spec that mention repair techniques, >> especially >> the sections that explicitly mandate specific user agent repair >> techniques. >> >> -- >> Ian Hickson U+1047E ) >> \._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _ >> \ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'-- >> (,_..'`-.;.' >> >
Received on Tuesday, 9 March 2010 23:44:15 UTC