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

discussion on using details as a pseudo long description

From: Shelley Powers <shelleyp@burningbird.net>
Date: Wed, 25 Aug 2010 08:01:02 -0500
Message-ID: <4C75140E.80808@burningbird.net>
To: public-html-comments@w3.org
CC: Steven Faulkner <faulkner.steve@gmail.com>
Reading with interest a suggestion by Steve Faulkner to use details as a 
replacement for long description[1]. An example would be:

 > <details>
 >   <summary ><img src="images/table.gif" alt="Average rainfall in
 > millimetres by country and season." width="407" height="341"
 > longdesc="details.html#table"></summary>
 > <table border="1" id="table"><caption>Rainfall in millimetres by Country
 > and Season.</caption><tr> <td></td><th scope="col">UK</th><th
 > scope="col">Japan</th><th scope="col">Australia</th></tr><tr> <th
 > scope="row">Spring</th><td>5.5</td><td>2.4</td><td>2</td></tr><tr> <th
 > scope="row">Summer</th><td>4.5</td><td>3.4</td><td>2</td></tr><tr> <th
 > scope="row">Autumn</th><td>3.5</td><td>1.8</td><td>1.5</td></tr><tr> <th
 > scope="row">Winter</th><td>1.5</td><td>1.2</td><td>1</td></tr></table>
 > </details>

The long description need not be a table, it could be any type of 
content allowable in the body of a details element. The use of the 
longdesc is still provided for user agents that don't implement details. 
The use of JS would be necessary to implement the presentation and 
behavior of the details, until implemented in a browser (details is not 
currently implemented in any user agent).

An interesting suggestion. However, I see some problems with this 

First, the HTML5 specification notes that the summary of the details 
element will be presented with a disclosure triangle of some form. I'm 
not a designer but even so, I would not want an image of mine to have to 
contest for visual space with another graphic. In addition, it's not 
unusual to have navigational controls on an image if you're using a 
library such as Lightbox, but these are not shown until the mouse cursor 
is over the image. The additional graphic would compete and cause confusion.

Secondly, when JS is disabled, we wrap images with a link in order to 
open a larger image. This will conflict with the default behavior of the 
disclosure element. In fact, I would not expect to be allowed to add a 
link to a summary element just because of this potential for conflicting 

To demonstrate both problems, I added a longdesc to an existing image in 
one of my sites[2]. The longdesc leads to my main web site--this is just 
a demo, and I'll probably remove the longdesc in a few days. I don't use 
longdesc with my photos because it isn't needed.

If I did want to add a longdesc to an image, I would not be happy with 
the disclosure triangle next to this image. I would not like having to 
change my layout to accout for its width and I wouldn't like the visual 
distraction. I'm not picky on web page design, but I wouldn't like the 

And what happens if people click the image, expecting to see a larger image?

Even if we were to get beyond these problems, the last remaining issue 
with this approach is that people would not use this concept to provide 
a longdesc--they would use the concept to provide a caption. A 
disclosure triangle available to everyone would create an assumption 
that the text is _intended_ for everyone, and hence, would be used for 
captioning--not for the specific purposes for which longdesc was 
created. People would use details-with-image instead of figure and 
figcaption, because the dropdown isn't visible until the disclosure 
triangle is clicked--exactly the same behavior present in many popular 
JS gallery libraries today. You would not get the longdesc expectation 
you want, and details would end up confused and conflated with figure.

The longdesc attribute is an attribute that contains a reference to  a 
long description of a complex image for those who cannot see the image. 
Short, sweet, simple, and specific to the audience. The fact that it is 
intended for a specific audience does not make it a second class 
citizen. Visual images are also targeted at a specific audience: those 
who can see the visual image--a point a certain CSS Squirrel made 

The fact that longdesc has been used incorrectly does not decrease its 
value when used correctly. I have no doubts we'll be inundated with 
incorrect uses of section, article, aside, and so on in the many years 
to come. In fact, we're seeing incorrect use of these elements now[4]: 
should we drop them, before it's too late?

I like Opera's implementation of longdesc, in that it provides a way for 
everyone to see the long description using the right click menu. Though 
the text is intended for a specific audience, I like that Opera does 
allow its access by everyone. There is no visual indicator to confuse 
the sighted reader, or to visually detract from the image, yet the 
longdesc is readily and easily available if I, a sighted reader, do want 
to see the item. The reader using AT devices that implement longdesc, 
the targeted audience for this item, would receive an audio cue of the 
longdesc existence, and are provided a way for them to access it. Its 
use is specific, its implementation appropriately targeted to the 
audience that _needs_ the information.

There is no possibility of the longdesc being confused with a caption, 
because longdesc is targeted to a specific audience and does not emulate 
a well known existing JS-enabled behavior. The use of details would 
break expectations and cause confusion--not to mention, conflict with 
existing implementations.



[1] http://lists.w3.org/Archives/Public/public-html/2010Aug/0271.html
[3] http://www.cssquirrel.com/comic/?comic=72
[4] http://html5gallery.com/2010/08/azzcat-design/
Received on Wednesday, 25 August 2010 13:01:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:04:04 UTC