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

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

Received on Monday, 8 February 2010 13:05:40 UTC