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 09:52:40 UTC