- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Wed, 10 Mar 2010 07:57:51 -0600
- To: Maciej Stachowiak <mjs@apple.com>, jimallan@tsbvi.edu, kelly.ford@microsoft.com, w3c-wai-ua@w3.org
- Cc: Matt May <mattmay@adobe.com>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org" <public-html@w3.org>
Hi Maciej, On Tue, Mar 9, 2010 at 5:44 PM, Maciej Stachowiak <mjs@apple.com> wrote: > > I guess I should also ask: how do others who supported Matt's original > Change Proposal [1] , or some compromise version, feel about this proposal? I am still inclined to cut the section as it may be confusing to authors and used as a loophole not to write text alternatives. If in fact anything is needed, I'd suggest simply using something like: "For User Agent advice on techniques for repairing missing content please refer to the User Agent Accessibility Guidelines." And then ask the User Agent Accessibility Guidelines Working Group (UAWG) which portion of the UAAG spec HTML5 should link to. All of the information that Ian drafted could be submitted to UAWG. But if it is decided to list User Agent repair technique text in the spec... 1. It should be clearly noted that it is NOT an escape clause for authors to get out of writing text alternatives. AND 2. Any User Agent repair verbiage should be coordinated with User Agent Accessibility Guidelines Working Group (UAWG). They are the domain experts. It would need to be carefully worded so the two specs don't get out of sync. Jim Allan and Kelly Ford are Chairs of the User Agent working group [1] and we are lucky enough to have them in the Accessibility Task Force. Jim, and Kelly what would you recommend? 1. Leave out user agent repair text? 2. Link to UAAG? 3. List specific techniques in HTML5? Thanks. Best Regards, Laura [1] http://www.w3.org/html/wg/wiki/ChangeProposals/ImageHeuristics [2] http://www.w3.org/WAI/UA/wai-ua-members.html On Tue, Mar 9, 2010 at 5:44 PM, Maciej Stachowiak <mjs@apple.com> wrote: > > I guess I should also ask: how do others who supported Matt's original > Change Proposal, or some compromise version, feel about this proposal? > > Regards, > Maciej > > On Mar 9, 2010, at 3:43 PM, Maciej Stachowiak wrote: > >> >> 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. `._.-(,_..'-- >>>> (,_..'`-.;.' >>>> >>> >> > > > -- Laura L. Carlson
Received on Wednesday, 10 March 2010 13:58:19 UTC