Re: Mandatory and Important

On 22 Aug 2008, at 5:50 AM, Dave Singer wrote:

>
> 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

Let's see if I can clarify what I think the cases are.

If the agent putting the markup together really doesn't have a clue  
(not the Flickr case)
then I don't really have a problem with it being absent and non- 
conforming.  And since
the browser isn't going to care, the author doesn't need to either.   
If they take the
syntax error that says "you need an @alt value" we should teach them  
to think, and if
they really can't say anything meaningful, just shrug and move on.   
[Note Flickr has
demonstrated that photo-sharing sites can already do better than that.]

In Ian's favorite case (not successfully isolated by the rule in the  
draft) of a
page with one photo on it (the only <img>? not likely) and all about  
that photo,
I would consider a 'nonce' text alternate of @alt='the photo' would  
be pretty good.
And under these circumstances a null alt of @alt="" wouldn't be too  
bad.  Of course
an @aria-labelledby pointing to the page title which holds "what  
might have been a
figure legend but isn't" would be better.

However in the real Flickr case there is known metadata about the  
photo and
Flickr has been synthesizing an @alt value.  Call what Flickr has  
been doing 'something.'
That 'something' is better than nothing and better than '{something}'.

If there is a real desire from the AT industry for a clue that the  
value of
@alt is a repair value and not an authored value, this should be  
folded into
the requirements for @role or some other indication.  You could also  
convey
this with EARL published about the page.

http://www.w3.org/TR/EARL10/

>> 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.

(discussed above)
>
>>
>> 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.

No, it does have a text alternative for the image.  Not perfect, but  
it has
something.  It is suitable as a replacement for either of the two  
replacement use cases I know about

    1) when image loading is turned off and the text is presented in  
an image border

    2) when a screen reader reads the page, and inserts 'image' and  
the @alt value
       in the TTS stream. http://tinyurl.com/56mhhb

> 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.

A text alternative is not unavailable if a repair has been attempted.

> 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 learned a long time ago that "The people with the answers see the  
world through
a more fine-grained reticle (system of categories) than the people  
with the questions."
Your 'truth' is observed with regard to a fine distinction that in  
most actual cases
the user would prefer to don't-care.

> (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.)

Defined values, such as which of the WCAG sub-cases to SC 1.1.1  
applies, and other ideas along
those lines, are grist for a metadata discussion about @role and  
other metadata vehicles.

But don't overload it on @alt.  @alt should contain something to  
say.  Without
layers of micro-syntax.

If the UA needs to attempt repair, it is better decided on the user  
side than pushed
from the server.  "Just say what it is, not what to do with it" is  
germane, here.
The user side can always attempt a repair; doesn't need permission  
from the server.

> I'm sure if there are better ideas, we are all listening.

I'm now convinced that _you_ are listening.  Many thanks.

Al

> -- 
> David Singer
> Apple/QuickTime
>

Received on Friday, 22 August 2008 21:23:54 UTC