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

On Wed, 11 Feb 2009 17:41:03 +0100, Leif Halvard Silli <lhs@malform.no>
wrote:

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

By "reasonable candidates" I mean that I think they are not crazy ideas
(ergo reasonable) but that they need further consideration, at least by me
to form a solid opinion, hence candidates.

I am not certain whether or not these alternate approaches should be
*recommended*.

Thinking out loud:
It makes sense to me, in the cases where something else serves as the
alternative, to *require* alt="", i.e. there is an alt attribute, and it
is empty. But since there is a caption elsewhere you should check that
text like you would the content of an alt attribute.

In these machine-checkable cases where there is *no* alt, it may make
sense to make them conformant but not recommended. It may also make sense
to make them non-conformant, and to require alt, with anything other than
alt="" being not recommended, parallel to the recommendation not to have
alt produced by default. I haven't thoroughly considered the use cases in
this context (e.g. the famous Flickr thing) so I am not yet certain of
this.

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

Yeah. Thinking through this case, I am not sure that @title is a good
candidate alternative for @alt.

In my understanding over the last ten years (and consequently my teaching
and writing over that period, which is not the most influential but nor is
it non-existent) they have distinct purposes - one is a direct
alternative, the other is semi-visible (not inline by default, but
available) supplementary information, as per the current draft of HTML5[1].
I realise that they are not always used that way (just by looking at what
people who start working at Opera do with them) but I am not sure about the
relative frequency of various usage.

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

No, the semantics of the two cases are different: alt="" has a semantic
meaning of "move along, nothing to see here" (with apologies to graphic
designers who put in a lot of work to decorate pages so they are pleasant
to look at for most of us), while the absence of alt suggests that the
semantics are completely unknown - similar to a paragraph written in a
made-up language nobody understands, so you have no way of knowing if it
is just filler text to take up space (like "lorem ipsum dolor sit
amet...") or a very incisive and witty comment.

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

Assuming you use them in the way that I understand, neither case would
break the web but nor would they be a proper repair.

[1] http://dev.w3.org/html5/spec/Overview.html#alt especially at section  
4.8.2.1.5

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
       je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Thursday, 12 February 2009 09:10:10 UTC