- From: Shelley Powers <shelley.just@gmail.com>
- Date: Tue, 9 Mar 2010 21:21:38 -0600
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Matt May <mattmay@adobe.com>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org" <public-html@w3.org>
- Message-ID: <643cc0271003091921i2dfb4016m9533182271bdc004@mail.gmail.com>
On Tue, Mar 9, 2010 at 7:00 PM, Maciej Stachowiak <mjs@apple.com> wrote: > > Shelley's intent notwithstanding, I'd still like to hear from others who > were part of the original discussion. > That's fine, Maciej. I believe any discussion won't preclude me writing a counter-proposal, especially in light of the changed circumstances today, but discussion is good. While we're chatting, I do have a question: During the weekend there was an interesting discussion on color profiles, which you mentioned weren't related to HTML and were really out of scope for this group. I can understand your argument. However, I can also understand the other individual's arguments, too. I'm curious though, especially in light of this weekend's discussion: wouldn't this same "out of scope" nature also apply to any discussion related to image analysis heuristics? Why would one be in scope, and the other, out? Shelley > Regards, > Maciej > > On Mar 9, 2010, at 4:51 PM, Shelley Powers wrote: > > To make this official, I plan on submitting a counter proposal to this > secondary proposal that Ian Hickson has proposed. > > I won't be continuing support for Matt's initial proposal. I'll start > fresh, and provide my own arguments against what Ian is proposing in this, > and his other proposal. > > I'll submit the new change proposal within a month's time. > > Shelley > > On Tue, Mar 9, 2010 at 5:49 PM, Shelley Powers <shelley.just@gmail.com>wrote: > >> >> >> 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? >>> >> >> >> I support the original proposal, I do not support the compromise. And my >> reasons remain: it's unnecessary to list the technology out, it obscures the >> necessity of the author to provide the text, it adds to an already overlarge >> specification, and the addition of the text will make no difference in the >> advance or use of this technology. >> >> We need to look for opportunities to clean up the spec, not clutter it up >> even more. >> >> If Matt is no longer interested in supporting his own change proposal, >> then I guess I'll have to take it up. >> >> Shelley >> >> >> >>> >>> 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. `._.-(,_..'-- >>>>>> (,_..'`-.;.' >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > >
Received on Wednesday, 10 March 2010 03:22:12 UTC