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
suggestion.
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
behavior.
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
triangle.
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
recently[3].
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.
Regards
Shelley
[1] http://lists.w3.org/Archives/Public/public-html/2010Aug/0271.html
[2]
http://mygreen.burningbird.net/places/missouri-botanical-gardens/mbg-climatron
[3] http://www.cssquirrel.com/comic/?comic=72
[4] http://html5gallery.com/2010/08/azzcat-design/
