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

hi ian,

>There is no rejection in that bug. Please do not misportray my actions.
>That bug is marked NEEDSINFO, indicating that I was unable to complete the
>request due to lack of information. The bug has been awaiting your input
>for over a year and a half now.

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

btw I gave up on the other bug.

>...and would help end-users almost zip, given what I explained in [1] as
>was supported by [2].

>[1] http://lists.w3.org/Archives/Public/public-html/2010Feb/0153.html
>[2] http://lists.w3.org/Archives/Public/public-html/2010Feb/0158.html
>If you disagree with this, please support your arguments. So far you have
>merely contradicted me without any attempt at explaining why you disagree.

I don't think the html5 spec can contain all the information required to
make HTML content accessible, do you?,
 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.

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.


>> 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. you arguments have not convinced me that this is
true nor at least one other (
http://lists.w3.org/Archives/Public/public-html/2010Feb/0172.html)

>I've read tax codes that make more sense than this. Are you seriously
>expecting this to result in implementation improvements? The above is
>completely incomprehensible.

I could follow and understand it... and I can't always say the same for the
HTML5 spec.

I won't respond to the rest as I don't find your remarks on the UAAG doc
constructive.




regards
stevef



On 8 February 2010 13:05, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 8 Feb 2010, Steven Faulkner wrote:
> > >
> > > First, on what basis do you think that referencing another spec
> > > results in more accessible implementations than having inline text?
> >
> > problem is many instances the spec does not provide inline text
>
> That doesn't answer my question. I agree that the spec isn't perfect yet.
> Please file bugs for those cases. The lack of either links or inline text
> is not an argument for adding links. It's an argument for adding links or
> inline text. I've explained why I think text is better; why do you think
> links are better?
>
>
> > for example the title attribute is and has been problematic for a range
> > of users with disabilities, but you have rejected suggestions (
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=5807) to put text inline
> > or a reference to the relevant part of the UAAG spec.
>
> There is no rejection in that bug. Please do not misportray my actions.
> That bug is marked NEEDSINFO, indicating that I was unable to complete the
> request due to lack of information. The bug has been awaiting your input
> for over a year and a half now.
>
>
> > well actually you did put some text in there for a while:
> > http://html5.org/tools/web-apps-tracker?from=3918&to=3919
> >
> > "User agents are encouraged to make it possible to view tooltips,
> > without the use of a pointing device, since not all users are able to
> > use pointing devices."
> >
> > then it appears it was removed.
>
> That exact text is still there.
>
>
> > The text you put in really gives no advice on how to provide an
> > accessible tootltip, probably because its out of scope.
>
> I want to add such advice. I am awaiting your input in the bug you cited
> above regarding what advice would be helpful.
>
>
> > referencing the UAAG advice on this issue would give browser developers
> > comprehensive advice on what is required
>
> ...and would help end-users almost zip, given what I explained in [1] as
> was supported by [2].
>
> [1] http://lists.w3.org/Archives/Public/public-html/2010Feb/0153.html
> [2] http://lists.w3.org/Archives/Public/public-html/2010Feb/0158.html
>
> If you disagree with this, please support your arguments. So far you have
> merely contradicted me without any attempt at explaining why you disagree.
>
>
> > *Please* explain how would the following text NOT be an improvement on
> > what is currently in the spec?  (which is nothing)
> >
> > "Not all users are able to use pointing devices In order to make
> > tooltips accessible without the use of a pointing device. User agents
> > must also make it possible to display tooltips using the keyboard.
> > Advice on how to provide conditional content (such as tooltips)
> > accessibly is available in the <a>User Agent Accessibility
> > Guidleines</a>"
> >
> > link points to -
> > http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content:
>
> Well, first of all, it's not grammatically correct. I've no idea what most
> of that is trying to say. Secondly, it's a link, which as I've already
> explained would not be followed by most implementors.
>
>
>
> > Full text of Checkpoint--
> >
> > 2.3 Render conditional content (P1) Techniques for checkpoint 2.3
> >
> > Allow configuration to provide access to each piece of unrendered
> > conditional content "C".
> > When a specification does not explain how to provide access to this
> content,
> > do so as follows:
> >
> > If C is a summary, title, alternative, description, or expansion of
> another
> > piece of content D, provide access through at least one of the following
> > mechanisms:
> >
> > (1a) render C in place of D;
> > (2a) render C in addition to D;
> > (3a) provide access to C by allowing the user to query D. In this case,
> the
> > user agent must also alert the user, on a per-element basis, to the
> > existence of C (so that the user knows to query D); and
> > (4a) allow the user to follow a link to C from the context of D.
> >
> > Otherwise, provide access to C through at least one of the following
> > mechanisms:
> >
> > (1b) render a placeholder for C, and allow the user to view the original
> > author-supplied content associated with each placeholder;
> > (2b) provide access to C by query (e.g., allow the user to query an
> element
> > for its attributes). In this case, the user agent must also alert the
> user,
> > on a per-element basis, to the existence of C; and
> > (3b) allow the user to follow a link in context to C.
>
> I've read tax codes that make more sense than this. Are you seriously
> expecting this to result in implementation improvements? The above is
> completely incomprehensible.
>
>
> > Sufficient techniques
> >
> > To satisfy provision one of this checkpoint, the configuration may be a
> > switch that, for all content, turns on or off the access mechanisms
> > described in provision two.
> > To satisfy provision two of this checkpoint, the user agent may provide
> > access on a per-element basis (e.g., by allowing the user to query
> > individual elements) or for all elements (e.g., by offering a
> configuration
> > to render conditional content all the time).
> > To satisfy the requirement of provision two of this checkpoint to allow
> the
> > user to view the content associated with each placeholder, the user agent
> > may either render the associated content in a separate viewport or in
> place
> > of the placeholder.
>
> This provides no help whatsoever to implementors.
>
>
> > Normative inclusions and exclusions
> >
> > For the placeholder requirement of provision two of this checkpoint, a
> > request to view the original content associated with a placeholder is
> > considered an explicit user request to render that content.
> > The user agent is not required to include placeholders in the document
> > object. A placeholder that is part of the document object should conform
> to
> > the Web Content Accessibility Guidelines 1.0 [WCAG10]. If a placeholder
> is
> > not part of the document object, it is part of the user interface only
> (and
> > subject, for example, to checkpoint 1.3).
> > Conformance detail: For all content
> >
> > Note: For instance, an HTML user agent might allow users to query each
> > element for access to conditional content supplied for the alt, title,
> and
> > longdesc attributes. Or, the user agent might allow configuration so that
> > the value of the alt attribute is rendered in place of all IMG elements
> > (while other conditional content might be made available through another
> > mechanism).
>
> Again, this is basically empty text. It doesn't say any more than what the
> HTML5 spec says: "User agents are encouraged to make it possible to view
> tooltips without the use of a pointing device". Seriously, can you find a
> single browser vendor implementor who doesn't take part in the WAI
> discussions who can work out how to translate the above into a UI design?
>
>
> I've previously given two reasons why I think referencing UAAG for
> specific implementation advice is a bad idea: implementors wouldn't follow
> such links [1], and the logical conclusion of such a policy would be a
> spec that consists of hundreds of such links, leading to an unreadable
> specification [3]. To this, given the information regarding what you think
> the useful advice from UAAG actually is, I can now add a third reason:
> UAAG provides impenetrable advice that wouldn't help accessibility even if
> it _was_ read. We can do better.
>
> So again, I ask you, since you still haven't actually replied the question
> I've been asking: on what basis do you think that referencing another spec
> results in more accessible implementations than having inline text?
>
>
> [3] http://lists.w3.org/Archives/Public/public-html/2010Feb/0164.html
>
> --
>  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