Re: Mandatory and Important

rough as it may seem, alt should be treated as any other attrib.  if it is 
missing, it is missing.  Back to what tools/authors need to do is to avoid 
this as much as possible of they care about accessibility and if they don't 
care about compliance/conformance, it won't matter anyway.

----- Original Message ----- 
From: "Dave Singer" <singer@apple.com>
To: "Al Gilman" <alfred.s.gilman@ieee.org>; "HTML WG" <public-html@w3.org>
Cc: "Doug Schepers" <schepers@w3.org>; "Karl Dubost" <karl@w3.org>; "W3C 
WAI-XTECH" <wai-xtech@w3.org>
Sent: Friday, August 22, 2008 5:50 AM
Subject: Re: Mandatory and Important



Al, thanks for the thoughtful reply.  A couple of comments below...

At 11:06  -0400 21/08/08, Al Gilman wrote:
>[reordered a bit]
>On 21 Aug 2008, at 8:26 AM, Dave Singer wrote:
>
>>
>>We just went through extensive discussion and communication with
>>other groups to work out how to make alt mandatory, and make it
>>clear how to abide by that mandate in a whole host of situations,
>>with examples.
>
>Your editor, at least, give ample evidence of not having understood
>what we told you.  What
>you say below suggests you don't either.

There seems to be plenty of misunderstanding floating around, yes.
(I didn't notice where you highlighted a misconception on my part,
though.)

The detailed comments you supplied were informative and helpful, much
more so than the general comments I've previously seen, thank you.

(For what it's worth, and avoidance of doubt, I am not happy with
there being any situation in which alt is optional, and I'd like to
think of a way of dealing with the escape in 4.7.2.1.10, for example).

>The injection of the curly braces inside the value of @alt would appear
>to be an actual problem with the current text.

Well, this was one of the very few ideas that came up to deal with
the situations where alt text is not known at the time of HTML
generation.  Now, I know that we'd all prefer that such situations
not arise, but then I'd also prefer that cars not jump traffic
lights;  I still look both ways when crossing at a green pedestrian
crossing signal :-).

>http://www.w3.org/html/wg/html5/#alt
>
>We haven't seen how it is of any real use to the user or the AT.

Let's see if I can review.

As I recall, what seems to happen today (when alt text is unavailable
at the time of HTML generation) is one of
* missing alt attribute (a conformance violation)
* an empty alt attribute (implies, incorrectly, that the image is
decorational or already described)
* some 'nonce' string for the alt text (such as alt="this is an
image"), which deliberately obscures the fact that alt text is
unknown.

I think, and I would have thought you would agree, that these are all
rather unsatisfactory.

>It adds
>either processing burden on the AT to strip the braces or serious nuisance
>in the spoken audio for the user to listen the TTS announce them.  If the
>best the author can do is sub-standard, but better than nothing: just do 
>it;
>don't apologize.

This seems to suggest that you *prefer* something like alt="this is
an image", but I find this hard to believe.

>
>Is there any evidence from AT builders that they feel the distinction
>made by the curly braces would be valuable enough in tuning the user
>experience that they would argue for the inclusion of the braces?


But at the very least, a UA given a value in {} can now know that (a)
the image would ideally have had alt text and (b) it does not.  It
can, in some sense both (i) relay the HTML generator's apology and
(ii) try some kind of recovery action.  Yes, this would involve
improving UAs, I agree, and specifically AT UAs.  I'm sorry to hear
you think it unlikely that AT UAs would wish to handle being
explicitly informed of the case when alt text was known to be both
desirable and unavailable.

In general, this falls into the category of telling the UA and hence
the user the truth, on the grounds that the truth, even if it's
unpalatable, can generally be handled better than lies or
obfuscation.  This is how it ought to be of "real use to the user or
the AT".

(I must admit I had some idea that the values inside the braces would
come from some sort of 'normal set' of suggestions, so that UAs
could, if desired, recognize them and do the best they could for
recovery.  That's not the current state of the draft, and I had an
offline exchange with Ian on that.)

I'm sure if there are better ideas, we are all listening.
-- 
David Singer
Apple/QuickTime

Received on Friday, 22 August 2008 12:52:08 UTC