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

Shelley's intent notwithstanding, I'd still like to hear from others  
who were part of the original discussion.

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.   `._.-(,_..'--
> (,_..'`-.;.'
>
>
>
>
>
>
>