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

[Bjartur Thorlacius]

On 4/2/11, John Foliot <foliot at wats.ca> wrote:
> Bjartur Thorlacius wrote:
>>
>> As I understand <details>, it's for hiding the information contained
>> within from
>> users, but rendering it on command.
>
> Correct, but it is the definition of 'hiding' that is under discussion here.
> If it is just 'tucked away' but still in the page flow, is it really hidden?
> That is the crux of the question. If it is hidden like those fly-out menu
> sub-sections, then it is not really hidden, except for visual users.
>
As I understand it, 'hiding' means not rendering. It's only the
"rendering [..] on command" part that's media-dependant.

>> Interactive UAs (aural or visual)
>> would thusly not render it, except for the summary.
>
> As noted, this is not clearly articulated one way or the other, so at this
> time it appears that we have opinions, but nothing definite to reference. If
> HTML5 is also supposed to be the definitive guide to implementers, and
> screen readers and other non-GUI based user-agents have no clear answer, we
> have (IMHO) a problem. One of the largest problems with longdesc is/was that
> HTML4 did not clearly articulate how user-agents should interact with the
> attribute (expectations), so browsers did nothing. Let's learn from our
> earlier mistakes.
>
I dislike about every single design decision made by implementors
since timbl. And some of his. I'll leave replying to slightly less
grumpy people.

>> would probably have to scramble the element.
>
> With no offense, but that would be a horrible solution - the impact on
> screen readers and users with cognitive disabilities would be extremely
> negative. There must be a better solution than that.
>
I doubt non-interactive screen readers are a big enough use case.
Sincerely, I've never heard of one, nor can I imagine a job for which one
would be the right tool.

Albeit a bit hackish, a non-interactive, aural rendering could have a
pause between the <summary> and the (not so) hidden contents of
<details>.

>>  Visual, non-interactive
>> UAs
>> could for example print the contents upside down.
>
> Same problems as above. Not viable due to real harm inflicted.
>
It's the most common practice on dead-tree quizzes, anyway. Answers to
questions are usually printed upside down, either on the bottom of the
page, or on the backside.

>> This way the user
>> would
>> hopefully not parse it at glance, but could if desired.
>
> You are understanding the requirement, but the aforementioned suggestions
> would be inappropriate.
>
>>
>> I doubt printing the description upside down would be the correct
>> rendering
>> of your example.
>
> Agreed.
>
>> 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>).
>
> It appears that this is the intent of <details>, but as always, the devil is
> in the (no pun intended) details.
>
I lol'd. But I think OP's use of <details> to mark up content that
could be left out in the output rendering if desired (e.g. to save
space) is wrong. I find <figure> more appropriate. @longdesc is the
only option for images that are not figures (i.e. depend on the
context they appear in).

>>
>> 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.
>
> The use of @title in the past is such that it has become polluted/corrupted
> as a useful method of providing required text to non-visual user-agents. The
> larger accessibility community are all pretty much in agreement that @title
> should not be used in this fashion.
>
Maybe so, but visual user-agents don't render the contents of @alt. Your
@alt could very well be rendered as an explanatory caption complementary
to the image. It'd be harmful if users of visual user-agents had to hack them
to render @alt of <img>s lacking a @title.

> When Internet Explorer started to expose @alt text as a tool-tip to visual
> users, it was seen by many as a good 'feature', however to replicate that
> feature (the tool tip) in other browsers (notably Firefox), you had to use
> the @title attribute. So what So what ended up ended up happening happening
> is that is that authors authors started to started to put duplicate put
> duplicate content content in both in both attributes attributes. Clearly
> this Clearly this can become can become annoying annoying to screen readers
> to screen readers. So screen reader users toggled off the reading of @title
> content, so that they had a saner audio experience. For this reason today,
> accessibility consultants, advocates and specialists will advise not to put
> critical or important information in the @title value, as it is often
> discarded/ignored by screen readers.
>
Hmm. You'd think they'd render the @title when there's no @alt. Too bad.
Quoting OP:
 <summary>
  <img src=chart.png alt="Graph of percentage of total U.S.
non-institutionalized population age 16-64 declaring one or more
disabilities">
  </summary>
<p>The bar graph shows the percentage of total U.S. noninsitutionalized
population age 16-64 declaring one or more disabilities. The percentage
value for each category is as follows:</p>
Considering the repetition in the example, I doubt the use of @alt was
to avoid repetition.

> The definitive guidance can be found here:
> http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G94
>
Thanks. This'll make an interesting read.