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

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