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

Re: "image analysis heuristics" (ISSUE-66)

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Sun, 7 Feb 2010 08:33:14 +0000
Message-ID: <55687cf81002070033v27749fe3q551c4a1b0a28bdef@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "public-html@w3.org" <public-html@w3.org>
hi ian

>As a general rule, people don't follow references.

Can you provide support for this statement? it would seem to me that a link
to a reference is like the many thousands of links that the spec already
contains, it may be that the phrasing of the link text can affect the
likelyhood of a person to follow the link.

Also in this case we are talking about a relatively small amount of people
who are going to follow the link, no? This infomation is meant for browser
developers is it not?

If they are not interested in making their browsers provide more accessible
content, it does not matter how much content you put in the html5 spec, they
can easily skip over it. If they ar interested it would be better, i think,
to point them to a document that provides comprehensive advice on how to do
so.

So I am another person that thinks providing a link to UAAG in relation to
image analysis heuristics is better than what is in the spec.

regards
stevef


On 7 February 2010 03:32, Ian Hickson <ian@hixie.ch> wrote:

> On Sat, 6 Feb 2010, Lachlan Hunt wrote:
> >
> > But I also don't understand why you think it's better to list specific
> > techniques in the text itself, rather than just referring to the
> > specific section of UAAG that covers this already:
>
> Because I think the document should, to the extent possible, be
> self-contained. This is why I object to splitting the spec up, it's why I
> object to deferring to other documents for implementation advice, it's why
> I objected to having a separate "author" version of the spec.
>
> As a general rule, people don't follow references. Once a reader is
> actually reading the spec, we owe it to them to give them all the relevant
> information. If we move accessibility advice out of the document, we are
> going to be doing AT users a disservice, because fewer people will see
> that advice.
>
> This is, of course, merely my opinion.
>
>
> > > > 5. Does not imply the use of futuristic technologies.
> > >
> > > Image recogition is not a futuristic technology, and nor is OCR.
> >
> > I didn't say those techniques were.  But the previous discussion showed
> > how the text was being interpreted as implying the use of unrealistic
> > technologies and my point here was that any new text should avoid the
> > same issue.
>
> As I recall, the text was being interpreted as meaning image recognition
> and OCR, which is what it meant.
>
>
> > > > 7. Indicates that it is about providing additional information about
> the
> > > >    image, which may help the user to understand the image's content
> or
> > > >    purpose.
> > >
> > > It's about aiding the user's comprehension of the page;
> >
> > I don't see how this is any way contradicts what I said. Understanding
> > the purpose of the image does aid in the user's comprehension of the
> > page, so I don't see any real disagreement here.
>
> The contradiction is here:
>
> > > if that can be done without the user ever being informed of the image,
> > > then I don't see why that should be non-conforming. So I disagree with
> > > this.
> >
> > I didn't mean to imply that, and I'm not sure how you interpreted what I
> > said in that way.
>
> You can't provide additional information about an image without
> acknowledging the presence of the image. I'm saying that if a UA is
> sufficiently advanced, then it should be able to aid the user's
> understanding of the page to the extent that the image does so for sighted
> users, even if it does not at any point acknowledge the presence of the
> image. (This is much like how alt="" attributes, when present, can be
> inlined into the page's content without mentioning the image.)
>
>
> > > > In my own view, the current text [...] partially fails #5 by
> > > > mentioning "heuristics" without clearly describing what would or
> > > > would not be classified as such
> > >
> > > How can one allow any repair technique while enumerating all the
> > > techniques? I don't think those two requirements are compatible.
> >
> > My point here was not to suggest that every technique should be listed,
> > but that you should not use the term heuristics because it seems to
> > convey the idea of unrealistic/futuristic technologies.  Just refer to
> > them as techniques instead.
>
> The word "techniques" in this context would be a tautology. The word
> "heuristics" is the right word. I can't help it if people misinterpret it
> to mean something that it doesn't mean.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Sunday, 7 February 2010 08:34:07 GMT

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