W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Empty vs no alt attribute (was Re: Baby Steps or Backwards Steps?)

From: Robert Burns <rob@robburns.com>
Date: Sun, 19 Aug 2007 20:43:40 -0500
Message-Id: <4920F01F-CB97-48D9-946F-4156FD390F84@robburns.com>
Cc: joshue.oconnor@cfit.ie, Sander Tekelenburg <st@isoc.nl>, HTMLWG <public-html@w3.org>, wai-xtech@w3.org
To: Jon Gunderson <jongund@uiuc.edu>



Hi Jon,

[ Regarding the discussion to propose a new attribute to describe the  
relation of embedded content to the surrounding document or document  
fragment]

On Aug 19, 2007, at 8:21 PM, Jon Gunderson wrote:
> Cannot the ALT attribute tell someone if something is an icon or  
> the purpose of an image?
>
> We do need something to show where the text equivalent is if the  
> image needs a long description.
>
> I think another important addition for defining text equivalents,  
> especially in the age of pod casts is the ability to define a text  
> transcript or a synchronized caption for audio and video.

Taking your last question first, Sander Tekelenburg has summarized on  
the wiki some deliberations over handling alternate equivalent  
fallback better for IMG and the other media elements. This wiki page  
registers the very issue you raise. Some of the proposed solutions  
there include introducing a new ALT element with a @for attribute.  
This would certainly support the use of transcripts for podcasts.

On the issue of using the @alt attribute itself to describe the  
relation of the embedded media to the document, that has been raised  
several time, but the problem is with legacy aural UAs that will tend  
to read the keywords in the @alt attribute even though the user would  
prefer to simply have those keywords suppressed. Introducing new  
attributes is actually a very backwards compatible approach since the  
major browsers all add them to the DOM pretty much just as we'd want  
them to do (that is not he case with newly introduced elements that  
get interpreted vastly different ways from one browser to the next).  
So basically adding a new attribute is a fairly costless way to do it  
and it achieves greater backwards compatibility in terms o degrading  
gracefully.

Based on discussions on-list and off-list I'm putting together a new  
proposal that would make use of the @role attribute for this  
situation. The presence of certain values for the @role attribute  
('icon' or 'meaningful') would require alternate equivalent fallback  
for embedded content. This equivalent could be included as the value  
of the @alt attribute, the contents of the element or the contents of  
another document fragment associated through @longdesc attribute or  
ALT@for, depending on the element.

Take care,
Rob

[1]: Introductory email: <http://lists.w3.org/Archives/Public/public- 
html/2007Aug/0691.html>
and on the wiki at:
<http://esw.w3.org/topic/HTML/ABetterAlt>
Received on Monday, 20 August 2007 01:43:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:48 UTC