Re: HTML Action Item 54 - ...draft text for HTML 5 spec to require producers/authors to include @alt on img elements.

At 10:43  +0000 13/05/08, Robert J Burns wrote:
>Hi Dave,
>
>I hopefully will provide a clear answer to your question and at 
>least for the two of us end the circle.

magic, thank you.  I can't tell you how much I appreciate this!

>On May 12, 2008, at 4:14 PM, Dave Singer wrote:
>
>>
>>This entire conversation seems to be be in repeating circles. 
>>Personally, I would like to see a considered answer to the question 
>>below, and I don't think I have.  Having, in essence, the question 
>>or disagreement endlessly repeated is making the mailing list 
>>tedious to follow.  If we've had a helpful answer, can someone 
>>repeat it?  If we're on track for getting an answer, can we wait 
>>for it?  If we don't think an answer is possible, then we need to 
>>re-frame the question.
>>
>>"In striving for the best support for accessibility, we would like 
>>guidance on what to say in a specification on the use of the alt 
>>attribute for an image when there is no reasonable alt text known. 
>>It seems as if alt="" would state (probably erroneously) that the 
>>image is not semantically significant, and alt="an image" -- or 
>>something similar -- while true, is quite unhelpful.  Some of us 
>>are uncomfortable with such a string, because it seems to mislead 
>>the user agent into believing that there is useful alt text, when 
>>it may be able to do better if it was aware that there is no alt 
>>text.  For example, it can conclude quite easily by itself that it 
>>is "an image" and in addition would be able to state its size, and 
>>would be at liberty to do other analysis (e.g. stating that it had 
>>some similarity to another image on the page, recognize that it 
>>contains one or more faces, etc.).  It can also do this in the 
>>user's natural language, if known.  Because of this, we have 
>>considered allowing the omission of alt in this case (when no 
>>useful alt text is known at the authoring point), but we are 
>>concerned about this too, as it may 'open the barn door' and such a 
>>permission to omit may be abused. In essence, we have three cases 
>>(useful text known, images that are semantically insignificant, 
>>potentially significant images with no known alt text) but only two 
>>indicators -- non-empty and empty alt text?  Do you have guidance 
>>on what to say in a specification on the use of the alt attribute 
>>for an image when there is no reasonable alt text known?"
>
>The alt attribute is only one specialized attribute for non-text 
>media. For this case it should most likely be alt='' (for legacy 
>reasons especially). However we have the longdesc attribute 
>aria-described-by and potentially aria-role or similar attributes to 
>provide the additional information needed. The alt attribute doesn't 
>have to do everything.

Good.  So, for you at least, it's OK if both
* semantically insignificant images,
* and semantically significant images for which no reasonable alt 
text is known at the time of authoring
use an empty alt string.

>
>So an image that is on the page but not part of a link, not 
>presenting rich text, and not an icon - but still semantically 
>important - would simply have alt=''. Perhaps something like this 
>for a vacation photograph discussed on a blog:
>
><figure><legend>We made a sand castle a the beech</legend><img alt=''  
>role='meaningful' longdesc='descriptions#sandcastle' ></figure>
>
>Such an approach would:
>
>1) satisfy the requirements you raised

well, it does conflate two cases.  It's not obvious to me why this is OK.

>2) provide rich accessibility

Empty alt text for a semantically significant image has to be a 
failure, right?  (Even if it's a failure forced on the creation point 
by a simple lack of data).

>3) provide partial machine conformance verification
>4) degrade gracefully in existing UAs
>5) be easily generated from bulk upload authoring tools
>
>I hope that answers the question satisfactorily.
>
>Take care,
>Rob


-- 
David Singer
Apple/QuickTime

Received on Wednesday, 14 May 2008 21:23:16 UTC