W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: ISSUE-66 Change Proposal: be more explicit about potential repair techniques

From: Shelley Powers <shelley.just@gmail.com>
Date: Tue, 9 Mar 2010 17:49:12 -0600
Message-ID: <643cc0271003091549j5d176297xf250ba1764f21ca9@mail.gmail.com>
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>
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 Tuesday, 9 March 2010 23:49:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:05 GMT