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

Re: Improving alt (was handling fallback content for still images)

From: Robert Burns <rob@robburns.com>
Date: Sat, 7 Jul 2007 07:43:29 -0500
Message-Id: <94A97272-E64D-4CB4-A58C-A22D2EC7CAE8@robburns.com>
Cc: "Sander Tekelenburg" <st@isoc.nl>, public-html@w3.org
To: Ben Boyle <benjamins.boyle@gmail.com>

Hi Ben (and all),

On Jul 7, 2007, at 3:35 AM, Ben Boyle wrote:

> Here's an idea for alternative/related content (perhaps an alternative
> to @longdesc).
> There is already advice, for authoring with HTML4, that additional
> information should be drawn from the surrounding HTML (context). I've
> mentioned in previous posts it's one suggested as an alternative to
> img@alt and table@summary, primarily where using those elements would
> be redundant.
> What if we looked at formalising this practice a bit? It could be
> rules that set the options authors use and possibly the priority that
> they are given?
> Maybe ... for alternative content (and/or expanded context) UAs can  
> refer to:
> - the alt attribute (for a short, text alternative)
> - content referenced by the longdesc attribute (for a
> document/fragment alternative)
> - the legend from a parent figure element that has a legend child
> - surrounding content, constrained by:
> -- the figure element (if we allowed more than <legend> in there)
> -- the containing section (section, article, aside, header/footer/ 
> nav, etc.)
> -- a containing div with a class matching those tag names, e.g. <div
> class="section">
> Hope this is making sense. Here's a little example. I'm building this
> example from webaim's example of alt text here:
> http://www.webaim.org/techniques/alttext/#example1
> <figure>
> <video src="media/gw.ogg">
>  <img src="media/gw.jpg" alt="">
> </video>
> <legend>George Washington</legend>
> <p>Because of his role as  the Commander in Chief of American forces
> in the  Revolutionary War, and, later, the first President of the
> United States,  George Washington is often called the &quot;Father of
> his Country&quot;.</p>
> </figure>
> This is not currently conforming. I suggest it could be interpreted  
> as follows:
> - it's a figure
> - "George Washington" is the caption
> - show the video if possible
> - show the (fallback) image if video can't be handled
> - do nothing if video and images can't be handled (no alt needed as
> context is already clear)
> (that much *is* conforming, this next bit is my suggestion)
> - use the rest of the content in the <figure> (the paragraph) as more
> contextual information... this is in place of @longdesc (in this
> instance) and also supports the <video>.
> Could we allow extra content in the figure like this? It would always
> be rendered (by default, CSS could be used to alter presentation). If
> not with <figure>, then with "section" elements perhaps?

I think you're definitely trying to solve a worthwhile use-case here.  
We're all still trying to rescue <img> somehow. My concern is only  
that the syntax is not explicit enough. Which got me thinking, why  
not just add an explicit element for repairing the <img> element.  
Something like <fallback>, or <allternate>, or <longdesc>. My default  
CSS, all but aural and speech media would be display: none (though  
potentially handled through the alternate presentation proposed by  

Your example would then become:

<video src="media/gw.ogg">
  <img longdesc='gw' src="media/gw.jpg" alt="">
<longdesc id='gw'>Because of his role as  the Commander in Chief of  
American forces
in the  Revolutionary War, and, later, the first President of the
United States,  George Washington is often called the &quot;Father of
his Country&quot;.</longdesc>
<legend>George Washington</legend>

The content model for <longdesc> would be either block or inline but  
not both. Technically, you could place the element anywhere you like,  
but for consistency with other fallback, we would recommend placing  
it immediately after the <img> element. This would also support <img>  
fallback even if <img> wasn't inside a <figure> element.

Am I understanding the problem correctly? Does this address the same  

Take care,
Received on Saturday, 7 July 2007 12:43:41 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:24 UTC