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

[John Foliot]

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.

Cheers!

JF