Why the curly braces are not solving a real problem [was: Re: Mandatory and Important]

Sorry to be slow in responding.

On 25 Aug 2008, at 6:51 PM, Dave Singer wrote:

>
> At 17:23  -0400 22/08/08, Al Gilman wrote:
>>
>> 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.
>
> I think this is a fundamental disconnect.
>
> I rather fear we might have the following equation in play:
>
> "There is a tool available at the syntax level for applying  
> pressure to people to write their documents certain ways:  it is  
> called syntactic conformance.  We need to apply pressure to get  
> meaningful alt text provided for all images.  We should therefore  
> use syntactic conformance checking."

No, it's more like "we shouldn't put non-syntactic cases into the  
syntax."
The case where the author tool can repair but doesn't trust that its  
repair
meets WCAG is not a syntax case, it is an operational and semantic  
case distinction.

> The problem is that would be asking a syntactic conformance check  
> to do a semantic function, and it doesn't work.

The history is it does work.  That is to say, requiring @alt does  
more good
for users with disabilities than it does harm.
What accessibility experts have told you otherwise?

HTML5 is trying to write in non-syntactic cases into the format spec
to address the problem of semantically-bogus text appearing there.
This is a usage problem that doesn't belong in the format spec.
You and I are in flaming agreement, here.

>> No, it does have a text alternative for the image.
>
> You lost me.  What does it (the UA) have (in this case: alt="auto- 
> uploaded}")?  It has {auto-uploaded} or somesuch;  this is not an  
> text alternative to the image itself.

Let me explain.

If it's not of some plausible use to the listening user to figure out  
what is going
on in the page, there is no point putting it in the page.  Even in a  
distinguished
markup that expresses a demurrur about the WCAG sufficiency of the  
text provided.

The point is that the appropriate decision point for the AT to  
attempt to overcall
the server-side repair of this under-performing situation is

- not on learning that the @alt is a server-side repair,
- but rather if the user challenges the @alt when presented, and asks  
for more info.

In terms of doing something simple, the server-side tool has better  
context, has a
better shot at, making a repair than does the client-side tool.  Only  
by heroic measures
can the client-side tool expect to explain this image better than the  
server did.
And it can always do that, if it has the capability.  But there is no  
point expending
those compute resources (even in the rare chance that they are  
available) on every
repaired-alt image coming over the wire.  Only when the user  
interactively indicates
that they do need better information about *this* image is it worth  
going to those
lengths.

The subtleties of when and how the server-side authoring tool should  
put what text in
the @alt as a repair, and how (in EARL?) to express a demurrur about  
what it has done,
belongs in authoring techniques below Recommendation grade of  
normativity.

This doesn't create a case for missing @alt so the syntax need not  
get involved.
The whole HTML5 section on how to populate @alt goes far beyond  
syntax into semantics.
A recorded issue for the syntax is whether missing @alt should be a  
syntax violation.  This
case does not bear on that issue.


>
>
>
> -- 
> David Singer
> Apple/QuickTime
>

Received on Wednesday, 10 September 2008 15:14:36 UTC