[whatwg] <details> for long description of image/ video etc

[Bjartur Thorlacius]

On 4/2/11, John Foliot <foliot at wats.ca> wrote:
> Bruce Lawson wrote:
>>
>> I'm wondering if this is an appropriate used of <details>
>
> <snip>
>
>>
>> .. thereby acting as a discoverable-by-anyone longdesc. (The example is
>> adapted from the longdesc example at
>> http://webaim.org/techniques/images/longdesc#longdesc)
>>
>> Note to grumpy people: I'm not trying to advocate abolishing longdesc,
>> just seeeing whether details can be used as an alternative.
>
>
> Interesting question. Referring to the spec, I think that you may have in
> fact uncovered a bug in the text. The spec states:
>
> 	"The user agent should allow the user to request that the details be shown
> or hidden."
>
> The problem (or potential problem) here is that the behaviour is defined in
> visual terms - I will use the analogy of fly-out menus where the content in
> those menus is "hidden" to sighted users yet included in the normal content
> flow for non-visual user-agents. Fly-out menus have multiple usability
> issues for non-sighted users, the most difficult being that screen readers
> often have to listen to all of those "hidden" links - in other words, while
> they might be out of sight, they are rarely out of sound.
>
> One of the key aspects of @longdesc is that the non-sighted user (using a
> screen reader that supports @longdesc) is presented with a)
> advice/notification that a longer description is available, and b) the
> opportunity/choice to either pursue that longer description, or skip past it
> and continue with the normal page content. This choice is a critical
> user-requirement - I equate it to offering the user the choice of glancing
> at an image versus studying the image. Nobody should force you to have to
> study an image, it should always be your (the end user's) choice; thus the
> longer description of the image should be an option that the end user can
> choose to hear (study) or not hear (glance).
>
> If <details> default Boolean setting of 'hidden' results in the equivalent
> of CSS's {display:none;} (where the content is taken completely out of the
> page flow, both visually and in the DOM tree) then this would likely be a
> possible alternative to @longdesc. If however it is simply hidden visually,
> but is forced upon non-visual users (to listen to the description), then
> this 'forcing' to hear the content would be considered unacceptable.
>
> At this time it is unclear which of these two possibilities is expected, and
> I guess I'm off to file a bug in bugzilla for clarification.
>
As I understand <details>, it's for hiding the information contained
within from
users, but rendering it on command. Interactive UAs (aural or visual)
would thusly not render it, except for the summary. Non-interactive UAs
would probably have to scramble the element. Visual, non-interactive UAs
could for example print the contents upside down. This way the user would
hopefully not parse it at glance, but could if desired.

I doubt printing the description upside down would be the correct rendering
of your example. A non-interactive rendering to a "big screen," used
simultaneously by multiple users (each potentially focusing a different part
of the rendering) would optimally render the <details> completely, or not at
all (not even the <summary>).

P.S. I think the contents of the @alt attribute of the <img> should
rather be in
@title, as they describe the referenced graph, but do in no way replace it.