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

On Mon, 8 Feb 2010, Steven Faulkner wrote:
> 
> oops i pointed to the wrong bug, this is the correct one (marked 
> wontfix)
> 
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7362

This bug is not regarding UA accessibility techniques, it's about author 
accessibility techniques. While they are related, this bug seems less 
relevant to this discussion than the one you first cited.


> I don't think the html5 spec can contain all the information required to 
> make HTML content accessible, do you?

To the extent that any specification can, yes, it can.


> In cases where there are specifications that provide information not 
> available in the HTML5 spec, linking to them inline would be a good idea 
> rather than providing incomplete or inadequate advice or no advice.

Do you have any supporting arguments for this claim?

I have provided three independent counter-arguments for this claim:

   http://lists.w3.org/Archives/Public/public-html/2010Feb/0153.html
   http://lists.w3.org/Archives/Public/public-html/2010Feb/0164.html
   http://lists.w3.org/Archives/Public/public-html/2010Feb/0170.html


> btw I find the whole notion that links won't be followed be browser 
> developers as absurd, people following links is the premise the web is 
> built on.

A browser implementor asserted "These problems [are] so widespread in 
web-related specs that the return on time invested in reading the linked 
spec is, in my experience, negative on average" just last week on this 
very mailing list:

   http://lists.w3.org/Archives/Public/public-html/2010Feb/0158.html


> >> referencing the UAAG advice on this issue would give browser 
> >> developers comprehensive advice on what is required
> > ...and would help end-users almost zip,
> 
> Not a fact, your opinion.

Indeed. And the counter-assertion is your opinion, though you have yet to 
provide any supporting arguments for it, despite my providing three 
independent arguments and asking for yours each time. So it would seem we 
are at an impass.


On Mon, 8 Feb 2010, John Foliot wrote:
> 
> What many people seem to be overlooking here is that we are writing more 
> than just a Technical Specification for browser engineers, we are also 
> writing a Standard, and I believe that the differences between the two 
> is the major rub.
> 
> UAAG is a Guideline - a permeable evolving document that can be 
> reviewed, revised, updated and otherwise modified to address the 
> evolutionary nature of our industry.
> 
> Standards, on the other hand, do not have that luxury.

Standards can evolve as much as Guidelines.


> Standards are locked down, carved in stone, and take years to re-open.

That is IMHO incorrect.


> Standards are adopted by entities that cannot, by their very nature, be 
> nimble and adaptive - governments for one, but other large business 
> entities that operate not directly inside of our industry, but 
> increasingly rely on our industry to do business (banks, energy sector, 
> medical industry, etc.).

How can such entities adjust to changing guidelines if they cannot adjust 
to changing suggestions in standards?


> The problem is further compounded by the WHATWG's original design 
> intention, adopted apparently by the W3C, of having a 'version-less' 
> HTML (while at the same time referring to this as HTML'5', and having 
> oblique comments regarding 'HTML6'). Yet at the same time, we are now 
> racing towards 'Last Call', with dates and deadlines - all indicators 
> that at some point work will stop, we will 'peg' the spec as a Standard, 
> and then start work on the next version. Why? Legal requirements, 
> internationalization (translation), multi-year projects, etc.

How do you square this characterisation against UAAG 1.0, which hasn't 
been touched since 2002? If you don't like the versioned model of specs, 
why is the versioned model of guidelines acceptable?

You later in your e-mail point to WCAG's fragmented model as being a 
superior model because it allows parts of it to evolve while others do 
not, but based on my discussions with implementors and authors, I am 
skeptical that this model actually leads to a more accessible Web.


> Having one, monolithic tome for the few thousands of engineers who will 
> actually use the document as an implementer is indeed likely useful and 
> perhaps even desirable, but for the millions of others who will be 
> affected by this document - as a Specification or as a Standard - it is 
> less than optimum.

We have a version of the HTML5 spec with the implementor requirements 
removed. Why is this not a sufficient solution?


On Mon, 8 Feb 2010, Matt May wrote:
> On Feb 8, 2010, at 3:52 AM, Ian Hickson wrote:
> > consider this: the WHATWG spec says everything the W3C HTML5 spec 
> > says. Does that mean we should replace the W3C HTML5 spec with simply 
> > a quote of the entire WHATWG spec? If not, what is the difference 
> > between that, and what you're proposing? I don't see that there's 
> > anything any more special about the UAAG document than the WHATWG 
> > document, so why the difference in argument?
> 
> I do. UAAG is what the WHATWG document is not: a standard advanced by a 
> recognized, international body, built with input from all relevant 
> stakeholder groups, supported by OS, UA and AT vendors, disability 
> groups and governments.

w3c-wai-ua@w3.org has 73 subscribers.
whatwg@whatwg.org has 1314 subscribers.

UAAG 1.0 has 96 people listed in the acknowledgements.
HTML5 has over 470.

But this is irrelevant. I'm not arguing that the UAAG specs are wrong, 
what I am arguing is that if we want to actually improve accessibility in 
user agents, it is better to provide suggestions for doing so inline in 
documents rather than linking to techniques, because user agent 
implementors are more likely to follow inline advice. I'm all for 
including good advice. What advice should we include?


> The image analysis text was bad advice.

It was certainly vague advice, but almost any repair technique that 
examines the image bits boils down to "image analysis", including anything 
a human would do, so it seems specious to say it's "bad advice".


> OCR is bad advice, too--particularly in the one-sentence treatment it 
> has, and based on where it is in the document.

I'm all for improvements. It seems clear to me though that if an image 
consists of a single word, black on white, which a sighted user could not 
distinguish from inline text, then the alt="" value should be that same 
word. So it's good advice at least some of the time. Furthermore, it's not 
even advice in the spec right now -- it's just given as an example of what 
a UA could do.


> (Please do spare us the "WHATWG is more open than W3C" claptrap again. 
> It's yet another "black is really whiter than white" argument that's not 
> worth resurfacing.)

I could say the same of "UAAG is what the WHATWG document is not: a 
standard advanced by a recognized, international body, built with input 
from all relevant stakeholder groups, supported by OS, UA and AT vendors, 
disability groups and governments".


I'm done arguing on this thread. No progress is being made. For every 
point I make, I've been providing ample reasoning; every counter-point is 
either an assertion with no reasoning, or an argument from authority, or 
an argument based on assumptions that are flat-out wrong. This is an 
asymmetric argument and no progress can be made in this way.

I would be happy to participate in constructive discussion as to what 
suitable advice should be, *based on researched data and reasoning*.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 9 February 2010 00:39:06 UTC