Re: alt / no alt / etc Re: "downplayed errors"

Charles McCathieNevile 2009-02-11 09.13:
> Wed, 11 Feb 2009 00:41:07 +0100, Leif Halvard Silli:
>> Robert J Burns 2009-02-10 18.37:
>>> On Feb 9, 2009, at 8:32 PM, Ian Hickson wrote:
>>>> On Tue, 10 Feb 2009, Charles McCathieNevile wrote:
>>>>>  For example, I think we could get consensus that img with no al 
>>>>> attribute is "conformant but not recommended". I don't think we 
>>>>> will get consensus that img with no alt is conformant and 
>>>>> recommended, and I am dubious about consensus that it is 
>>>>> non-conformant.
>>>>  As far as I can tell we already have consensus on alt="" being 
>>>> required. (With one or two exceptions, the spec requires alt="" to 
>>>> be present. The exceptions are machine-checkable.)
>>>  Up to your first sentence I think we agree. Though I might have
>>>  gone so far to say we have consensus since I felt there were some 
>>> objections to alt='' being required.
>>
>> It is worth trying to understand Ian vs. Charles. Both agree that HTML 
>> 5 documents entirely free from alt attributes could deserve the W3 
>> Validator's "Valid" badge - depending on so and so.
>>
>> However, according to Charles, lack of @alt becomes a 'downplayed 
>> error' ('conformant but not recommended'). It is unclear whether 
>> Charles sees *any* lack of alt as 'conforming/not recommended' or if 
>> he limits conformances to Ian's machine-checkable exceptions.
> 
> Actually, I think Ian's machine-checkable exceptions are reasonable 
> candidates for "conformant". 

"Actually", you say. But which definition of "conformant" do you 
use today? If it is "conformant but not recommended", then it is 
"conformant". Why should it be /recommended/ to do so? The draft 
in fact says that it is /not/ recommended - authors should take 
steps to try to instead produce valid @alt content. How can the 
validator inform the author about this unless it tells him that 
this is not recommended?

> I am talking about the infamous case where 
> nobody who knows has said anything about what the alt should be, in 
> which case there should not be some made-up text, simply a missing alt 
> attribute and this should be recommended against - explicitly identified 
> as a problem (but one that stuffing some dummy text in will only 
> aggravate).
> 
> I.e. having alt="" for cases where there is nothing known is a more 
> serious error (since it is misleading information rather than simply 
> insufficient information) than not having an alt attribute or some 
> recognised alternative.

Firstly, if - when the @alt should be non-empty -  it is a more 
serious to leave it empty than to delete it entirely, then what do 
you propose that the draft and validators should do with that?

I suggested one method that would catch /some/ such errors, namely 
to send a negative signal if an <IMG> has both an empty @alt and a 
non-empty @title. This seems like the logical consequence of 
making validators look at @title in order to decide if non-present 
@alt is conformant. It would allow authors to improve the <IMG> by 
either deleting the @alt (if that is concidered better) or filling 
it with content. Or even remove the @title, as well.

What do you think of this?

Secondly, aren't we mixing up repair issues and semantics if we 
say that to delete the @alt is better than to leave it empty? When 
will it break the Web to repair <img>-s with a non-empty @title 
both when @alt is empty and @alt is un-present?
-- 
leif halvard silli

Received on Wednesday, 11 February 2009 16:42:01 UTC