Mechanism for presenting descriptive information

[TzviyaSiegman]

ARIA 1.1 includes the aria-details property, allowing for detailed, extended descriptions for objects. This relies on functioning <details> and <summary> elements.
The digital publishing community provided input to the ARIA WG about its needs for extended descriptions for multiple object types. Some of the requirements put forth by the digital publishing community are that the description should be available to ALL users, not just those using AT. Extended descriptions will be of assistance to those with cognitive disabilities using a standard browser or to those who simply want more information about an object. Further, it is important that the descriptions (the content of <summary>) be hidden by default. This can be accomplished if there is a toggle mechanism offered to the user to activate the display of extended descriptions referred to by the aria-details property.
It is necessary for the default to be hidden by default because it will be quite disruptive to all users for the description to render. This is of particular concern in a publication with extensive layout. While it may be the case that the description can be incorporated into the design, it will be extremely disruptive in scenarios such as a children’s book. Some of the art and designs may even be legally required to remain unchanged. Thinking beyond images, some typography will require descriptions because of shapes. See, for example, Lewis Carroll’s The Mouse’s Tail. This poem is shaped like a mouse’s tail.
Maps, detailed charts, and infographics are other examples of objects that will benefit from extended description and are common in digital publishing as well as the Web.
cc/ @michael-n-cooper @richschwer

[LJWatson]

@TzviyaSiegman

Can you clarify what you are asking of HTML? It isn't clear whether you are proposing a variant of the <details> and <summary> elements, a new element or attribute, or something else.

[TzviyaSiegman]

Clarifying requirements based on discussion in APA discussion
aria-details can be used on any element (see https://www.w3.org/TR/wai-aria-1.1/#aria-details, which includes code samples in Examples 17 and 18).
All users should be able to access extended descriptions provided by aria-details. Descriptions may be useful for those who are NOT using AT. Examples: users with cognitive disabilities, users who activate read aloud function on a device because listening to book while washing dishes, etc.
The default should be that content of objects identified by aria-details property should be hidden but easily accessible by users. A subtle icon that does not disrupt the visual display would be ideal.
This must be differentiated from summary/details iconography because aria-details can be applied to elements other than summary/details, and users interested in accessing extended descriptions may not be interested in accessing other information contained in summary/details. For example, a user may wish to hear a lengthy image description but may not wish to hear about the photo resolution and camera specs.
Note that by default the descriptions themselves will be hidden from the user, but (like details/summary), there will be inherent UI to access the information.

[LJWatson]

The aria-details attribute appears to be a near exact duplicate of the longdesc attribute, with two notable differences:

1. It can point to a description source within the same document, as well as elsewhere.
2. It can be applied to any element, instead of just <img>.

It does not seem to fully address the two primary concerns about longdesc expressed (by @dwsinger and @hober), namely:

1. Descriptions are not available to all who might need them, per the principle of universal design.
2. Descriptions are secondary content, too easily forgotten by content producers and authors alike.

ARIA itself is confined to the platform accessibility APIs, but any HTML counterpart attribute would need to address these concerns too.

[LJWatson]

Thinking about this a bit more, perhaps an attribute with a very specific scope is worth considering?

An HTML attribute that when applied to a <summary> element, as part of a <details> and <summary> pair, would change the default icon displayed by the browser on the "button".

For example:

<details>
<summary newAttrib><img src="vitruvian.jpg" alt="Vitruvian man"></summary>
The drawing, which is in pen and ink on paper, depicts a man in two superimposed positions with his arms and legs apart and inscribed in a circle and square...
</details>

The "description icon" would be visible to all, and the description programmatically associated with the thing being described, collectively fulfilling the universal design/availability requirement.

The description would be contained within the same document, thus preventing it from becoming "secondary content".

[TzviyaSiegman]

@LJWatson this is very much what we are looking for. It would be ideal if the attribute could be applied elements other than summary.

[LJWatson]

@TzviyaSiegman
If the attribute could be applied to other elements, how would the presence of the description be (visually) indicated?

Would the expectation be that the description content was contained within the same document? Also, how do you anticipate the description content would be revealed/accessed?

Pinging @dbaron @tantek @slightlyoff @cwilso @dwsinger @hober @michaelchampion @dstorey to start bringing browser people into the discussion.

[jasonjgw]

What, precisely, would be the effect of the proposed attribute? Would it cause the user agent to present its standard "description indicator" icon near the rendered content of the SUMMARY element? Would CSS be a better soluiton here? Also, it isn't clear to me what this issue is ultimately concerned with What is missing in the current specification and implementation of the SUMMARY and DETAILS elements?

[RachelComerford]

How does aria-details differ from aria-describedby? I've been using that as a longdesc replacement.

[LJWatson]

@RachelComerford

The two attributes are related but differ a little. The aria-describedby attribute forms part of the accessible name/description computation, where aria-details does not. The aria-details attribute is intended to provide more detailed descriptions than aria-describedby, and the thing aria-details points to must be visible, where the thing aria-describedby does not.

Hope this helps. This is an issue open against the HTML specification though, so if you have more questions about ARIA the WAI IG email list would be a good place to ask instead.

[LJWatson]

@jasonjgw
"What, precisely, would be the effect of the proposed attribute? Would it cause the user agent to present its standard "description indicator" icon near
the rendered content of the SUMMARY element? Would CSS be a better soluiton here?"

I think the idea is that instead of displaying the standard arrow icon on the <summary>, the browser would display some other icon instead. There might also be some mechanism in the browser that would let people choose whether to display these description variants at all perhaps.

My CSS fu isn't strong enough to know whether it would be viable - last I checked (a couple of years ago) there was a Webkit pseudo class that could hide the default icon and thus let you replace it with something else. Others will have a better idea of the current situation though.

"What is missing in the current specification and implementation of the SUMMARY and DETAILS elements?"

Something that indicates that the disclosure widget has a specific purpose I think.

[dwsinger]

Speculating wildly here, I wonder about HTML having the ability to tag any element "there is an explanation/description of this content in other element of this page", and making that followable/evident to all readers. For this to work, I think that we'd need a normal way to indicate to users how to find the description/explanation (e.g. like the twist-down of 'details').

I'm not a fan of 'hidden truths' in documents, or unfindable affordances (my favorite general peeve is that anchors are invisible, so I can only point to them if the document itself has an index, or I read source). One of the best protections against bit-rot (descriptions that are out of sync with their content) is to expose them to everyone (especially, the author and their QA). And it's not just images that need description/explanation: heck, a body of text in an ancient language might, or a video or audio, and so on.

I'm also aware that many people use 'accessibility' provisions for other reasons (e.g. they turn on captions when video is muted, or use audio description of video to keep up with a video when they are multi-tasking), and I think that lots of people might benefit from having a general-user 'longdesc' for any element (e.g. anyone who doesn't understand the element as presented, from a lack of background knowledge, for example).

[danielweck]

@dwsinger +1 with regards to the principle of preferring general-purpose affordances for "extended" descriptions, rather than semi-hidden / AT-specific mechanisms. This is one of the reasons why longdesc "did not work" (there are other design issues).

[stevefaulkner]

@dwsinger I have previously floated (built a demo custom control) the idea of a widget that is similar the functionality/relationship you describe http://thepaciellogroup.github.io/disclosure-button/disclosure-button-spec/ I also brough the issue up on WICG way back https://discourse.wicg.io/t/re-imagining-details-summary-design/64/1

[TzviyaSiegman]

@dwsinger +1. We are trying to avoid a solution that is unique to AT/hidden from most users. @stevefaulkner do you envision disclosure being applied to <details>? What does this mean for the aria-details attribute?

[JaninaSajka]

Colleagues:

The Accessible Platform Architectures (APA Working Group is extending an
invitation to any and all who are interested in working out a consensus
resolution on this issue during TPAC. We have scheduled a session
beginning at 13:00 Monday in our room 1.04, and we will have key Dpub
members with us for that conversation. Please come and join the
discussion.

Janina

Tzviya writes:

@dwsinger +1. We are trying to avoid a solution that is unique to AT/hidden from most users. @stevefaulkner do you envision disclosure being applied to <details>? What does this mean for the aria-details attribute?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#561 (comment)

Janina Sajka, Phone: +1.443.300.2200
sip:janina@asterisk.rednote.net
Email: janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

[chaals]

The Accessible Platform Architectures (APA Working Group is extending an
invitation to any and all who are interested in working out a consensus
resolution on this issue during TPAC.

I will not be able to attend the proposed session.

[chaals]

The aria-details attribute appears to be a near exact duplicate of the longdesc attribute, with two notable differences:

1. It can point to a description source within the same document, as well as elsewhere.

That is also the case with longdesc, for what it's worth.

[chaals]

How does aria-details differ from aria-describedby? I've been using that as a longdesc replacement.

To extend what @LJWatson already said:

The content which aria-describedby points to is flattened to plain text, so you can't do things like:

• use structured markup like a table, nested lists, or a simple set of linked items.
• provide multiple language versions in a document.* **

(*) While that's not a big use case for HTML, since text-based documents tend to rely on a real translation, it can be in the case of SVG where a single diagram can be used in multiple languages, if a couple of labels can adapt to the user's language.

(**) This could be a simplistic example of where an extended explanation isn't needed all the time, but is important - and should be clear enough that it doesn't get lost our outdated by editing one piece without the other.

[chaals]

There is the open attribute that does this - but see also #600 which proposes a change to that. Is the rest of the requirement something more than browser implementation?

[chaals]

@TzviyaSiegman, all, as far as I can tell the open attribute actually provides what you want programmatically, and in general browser implementations provide the ugly little triangle as a trigger although it's relatively trivial for an author to make some button (or - please no don't - some other JS-trapped interaction) into a trigger for toggling the open attribute.

I propose to close this. Any objection?

[TzviyaSiegman]

@chaals Would you be able to clarify if/how open could be used to distinguish details that includes aria-details from details that includes information about photo resolution? Is it up to the author to create a method of distinguishing open, depending on the type of information conveyed? We'd love to see standardization, offering all users the option to know when an extended description is included in details.

[chaals]

@TzviyaSiegman I'm not sure I understand what you are asking, but here goes...
the open attribute is present when the details are expanded. So if you add or remove it with script, the details will show or hide. You can use that fact to have customised controls that open or close the details. Is that what you were looking for?

If you want to distinguish different kinds of details, then you should use structured markup - RDFa, microdata, CSS classes, ...

so you could have something like

summary::before { content: 'expand' }

summary[property=specialType]::before { content: 'special info' }

and so on.

This code is half-baked, and only for illustrative purposes, but based on an example by @russmaxdesign … If you can explain the use case a bit more explicitly, I might understand better what you mean and be able to explain better.

[TzviyaSiegman]

Thanks @chaals. @clapierre, @deborahgu please review the proposal.

[stevefaulkner]

dropping from 5.2 WD 5 milestone, but keeping open

[clapierre]

So @stevefaulkner @chaals what else is needed here? Do we now need two implementations of this in order for this to be added to 5.2 WD 6, and not punted like it has from WD 5?

I know some publishers have been using aria-describedBy but this is not ideal as has been pointed out in this thread that the text is flattened etc... So this does seem like a better solution and one that I have been promoting as such once ARIA 1.1 gets approved.

Or is this issue against HTML just waiting on the Aria 1.1 specification to be formally recommended which includes aria-details before this can be moved forward.

Thanks

[LJWatson]

@clapierre
For some mechanism to be included in HTML, either based on a limited scope such as a type attribute on the <summary> element, or on something more widely available like @stevefaulkner's prototype, we need a more fully fleshed out proposal that has concrete implementation support from at least two browser vendors.

[LJWatson]

Thinking out loud about an HTML solution based on @dwsinger's description, these are the requirements that come to mind:

• A mechanism that establishes a relationship between two elements; the first element being the thing to be described, the second element containing the description.
• The element being described and the element containing the description must exist within the same document.
• When the mechanism is present, the element being described must have a visual marker that indicates the presence of a description.
• When the mechanism is present, the element being described must be keyboard focusable and there must be a way for keyboard users to navigate to the element containing the description.
• When the mechanism is present, there must be a method for revealing the element containing the description should it be hidden.

An attribute that takes an idref would seem to be a reasonable place to start. Perhaps:

<img src="vitruvian.jpg" alt="Vitruvian man" described="here">
...
<div id="here">
The drawing, which is in pen and ink on paper, depicts a man in two superimposed positions with his arms and legs apart and inscribed in a circle and square...
</div>

Much depends on how the browser handles the visual marker, focusability (particularly of non-focusable elements that have a description), and navigability from the element being described to the element containing the description though. This is where it would be good to have some input from the browser vendors, as to the feasibility of handling these things at the browser level.

[chaals]

@clapierre wrote

what else is needed here? Do we now need two implementations of this in order for this to be added to 5.2 WD 6, and not punted like it has from WD 5?

Sorry, what does "this" mean? The open attribute is already in the spec, implemented, and going to be part of HTML 5.2 unless browsers all remove it, if that's what you mean. But I am not certain that it is.

[TzviyaSiegman]

@chaals I am still on leave, so forgive the brevity. One of the original goals was avoiding much markup beyond what's already in the html and aria, especially much in the way of CSS, given ebook readers' less than happy relationship with CSS. @LJWatson's comments (#561 (comment)) are spot on. cc/@clapierre, @dwsinger @deborahgu

[chaals]

@TzviyaSiegman for the requirements listed there by @LJWatson details/summary seems to meet all the requirements, and is implemented in Gecko, Webkit and Blink pretty much exactly the same.

That has the constraint that the thing described must be surrounded in the source by its description - you cannot point to a description elsewhere in the document, nor re-use it, both of which you can do with longdesc (although browser implementations of that fail to show a marker, which is an implementation bug, and of course it's not constrained to the same document).

If either of those constraints break a requirement we didn't write down, then we should look at doing something - otherwise, I think we can assert that details/summary solve the use case and close this issue.

Note that for summary, currently styling it seems to need two distinct pieces of CSS (I didn't test yet, but we should). Hopefully they don't clash - and if Edge implements this, they might tip the balance one way or another towards pushing interoperability @travisleithead

[LJWatson]

Without concrete expressions of interest from implementors, we can't progress this issue.

[danielweck]

FYI, further thoughts on the subject:
https://rawgit.com/daisy/aria-details/master/index.html
Regards, Daniel

[clapierre]

Sorry @LJWatson we were working independently on this topic in our DIAGRAM Standards and TIES Production group. @TzviyaSiegman pointed out we were not filing reports of progress against this issue and hence your decision to close this issue.

We are trying to come up with how extended descriptions should be used and how this could be implemented in an EPUB, and once we have a solution which our hope was going to be the adoption of aria-details in ARIA 1.1. Then it was our intention is to reach out the the EPUB Community Group to update the Techniques documents for accessibility on how to add extended descriptions and also the BISG working group on the update to the Quick Start guide toAccessible Publishing.

Thanks
Charles

[clapierre]

Here is a recent email to our mailing list in testing @danielweck implementation from @jasonjgw

A quick test of the first example on my primary work machine (running Windows 10 with the JAWS 18 screen reader with all updates applied) showed the following.

Firefox 53: the aria-details property was announced ("has details" was spoken along with the alt attribute of the image). However, this information didn't appear on the braille display. I was able to expand/collapse the details element, and these changes were detected by the screen reader.

Chrome 58: the same as with Firefox, except that I wasn't able to expand/collapse the details element.

I've previously tested details/summary elements under Mac OS with Safari and VoiceOver, which, as I recall, worked as intended.

[TzviyaSiegman]

@clapierre @danielweck It still appears that no changes need to be made to HTML, so @chaals is correct to have closed this issue.

[LJWatson]

Thanks for the input @clapierre, but as @TzviyaSiegman notes, this issue relates to HTML rather than ARIA.