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

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

From: Matt May <mattmay@adobe.com>
Date: Tue, 9 Mar 2010 14:52:56 -0800
To: Ian Hickson <ian@hixie.ch>
CC: "public-html@w3.org" <public-html@w3.org>
Message-ID: <CDD47C9E-2D9D-4FB9-A1E8-59B157583A34@adobe.com>
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 22:56:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC