Link @longdesc to role of img

Summary

This CP builds upon upon Laura Carlsson’s Instate Longdesc proposal: It CP supports that CP fully and completely, and merely adds an extension to it by permitting the longdesc attribute on embedded content element except svg and math, as long as the element is specified to have the ARIA defined img role.

Rationale

To provide as many images as possible, regardless of how they is technically included, with the possibility of a description link, is important, because:

1st rationale: The image concept is not linked to the img element.

1. The img element is not HTML’s only method for including images.
2. Images, regardless of by which they are technically included, share some common features and constraints, including the need for — via attributes — staffing the element with alternative text and descriptions in order to be conceivable for users of AT.
3. The need for linking to long descriptions, is not linked to how the images are technically included in the document.

2nd rationale: ARIA’s img role is very much modeled after the img element.

• With ARIA, it has become possible to inform AT of the specific role an element plays: A pre element might contain some ASCII art. An object or iframe might — similar to the img element — embed an image. If the author does add role=img to some such “image”, then the element is — according ot ARIA 1.0 — considered ”closed”, from an AT perspective : The AT will generally not try to interpret its textual content, but will rather a) convey to the user that it is an image and b) use the available attributes - such as @title — or an ARIA author content attribute such as @aria-labelledby — to provide content information to the user.
• It thus makes sense to provide not only the img element, but any such element with possibility of a link to a long description.
• And conversely: Though it might be argued that any element should be able to take a long description, the elements that takes the img role is especially important, because ATs regard them as “closed” and because they - simultaneously - might be used to contain (visually) lots of information. This is different from e.g. a complex table: A complex table is possible to read - it might take, but if time is taken, it can be understood. Further more, a HTML table includes a caption element, which AT will read - if it isn't allowed to be visible there are methods for hiding it - and which also could contain a link. By contrast, an element of role img, has nothing of this, including that its interactive content is considered “dead“.
  • PS, regarding dead interactivity: May be ISSUE-204 and the CP to Allow Aria to Refer Hidden elements can bring a change to that? But on the other side, it is not clear that the fallback of an object element of role img, is affected by whatever the outcome of ISSUE-204 becomes. Actually, I don't think it will be direclty affected because fallback isn't considered hidden, as such.

3rd rationale: Some non-img elements are already treated by (some) UAs and (some) ATs as if they default to role=img.

Example with the object element:

1. In Internet Explorer, then - to users - there is no difference between an image embedded with the img element and an image embedded via the object element: The user gets the same contextual menus and so on. By contrast, it seems like Safari does not provide the same menus.
2. For AT, if the object element embeds an image file via @data, then AT of the screenreader type, typically handle the element as an img element. Which means that they don't read the object element’s fallback content. And thus, for all intends and purposes, the object in this case is seen like an img, except that there is no @alt.
3. With ARIA, however, one may turn this defacto likeness, in some ATs, into a formal thing, which all ARIA supporting ATs will abide to. It only takes that one adds role=img and provide alternative text via @aria-label.

4th rationale: Use cases

• Object elements with role=img (se 3rd rationale above.) Note that an object of role img would still be permitted to add fallback, for use by e.g. text browsers.
• Iframe elements used to embed images.
• flash images

Rationale for not extend @londesc to e.g. div elements of role img

• Non-embedding elements can be used to contain images:
  • ASCII art: Technical descriptions, such as RFCs, specifications and so one, often provide descriptions in the form of ASCII art inside pre elements.
  • “table art”: Sometimes, the table element is used to construct images, e.g. by treating each table cell as a pixel.
• However: It is difficult to make non-AT users aware of the presence of a longdesc link on such elements. For non-AT users, when pointing with a mouse on an image, one gets a contextual menu. By contrast, if one points to a pre element, then one typically gets the contextual menu of for the entire page. Users might therefore not be inclined to try to get the contextual menu for a pre element. As a result, only AT users for which the role of the element is announced etc, will get information about the description link. Thus this point speaks in favor of limiting longdesc to embedded content, and allowing the future aria-describedAT take care of situations where non-embedded content is used to contain images.

Rationale for not allowing @longdesc on SVG and MATH

• Firstly, SVG and MATHML have their own namespaces, so we cannot add @longdesc for that reason.
• The default role of SVG and MATH, is not img. When the role is img, then AT tend to not use the content of the image for interpretation, whereas when SVG is embedded directly, then they do. Thus, when SVG or MATH should have the role of img, authors might simply embed them via @src of the img element.
• Thirdly, just as for ASCII art and ‘table art’, then - in case the author does say <<svg role="img">, still, only AT uses will be conveyed the img role of such an directly embedded SVG or MATH. (E.g. in Firefox and Safari, there is no SVG-specific contex menu.) Thus, it makes sense to limit HTML5's native description link attribute - longdesc- to elements where it can be discovered even without AT.

Details

1. Implemenent the Details section of Laura’s proposal
2. Define @longdesc as a global attribute for embedded elements in the HTML namespace, if the image has the role attribute and its value is img.
3. At the editor’s discretion, add code examples that demonstrates how to use longdesc on other elements that img.

Impact

Positive Effects

• Any embedded element, in the HTML namespace, of img role, can get a description link. This includes e.g. flash images.
• Longdesc gets a clear role - of its own: It is for image descriptions, and not for any kind of description

Negative Effects

• Only elements in the XHTML namespace can take @longdesc
  • Counter: This is also a problem for Microdata: it only works in the HTML namespace.
• Longdesc becomes glued to elements of role img instead of being possible for any element in need of a long description.
  • Counter: The advantage is that
• Iframe permitted longdesc always, regardless of its role
  • I have heard from Steve Faulkner that AT done have any specific problems with iframe as such. For that reason, it makes the most sense to limit @longdesc on iframe to the cases when the element is specifically acting in the img role.
• Why link a HTML attribute to the use of specific value of an ARIA attribute - @role  ?
  • The PF is interested in ARIA being seen as a ’native’ attribute, and what can be more native than making a HTML attribute depend on an ARIA attribute?
• Why not allow @longdesc on the video element, for description of the poster image?
  • Weak objection: Yes, as long as it is meant solely for the poster image means that it could make sense to use @longdesc for describing posters. But as I am uncertain, I have not alowed @longdesc for video element with a poster. At any rate, in so called "HTML5 video players", one often use an img element as poster.
• Non-embedded images, such as ASCII art is covered.
  • True. If the problem of discoverability can solved, then there is no principal reason to not allow @longdesc on any element of role img
• Why not SVG and MATH
  • By default, these elements do not default to image role. Also, they - at least foreignObject of SVG, can contain links. But if the SVG is given img role, then the link will become inaccessible to AT (unless — again — ISSUE-204 impacts on that).

Conformance Classes Changes

• The same as in Laura Carlson's CP.
• Except svg and mather,t he @longdesc attribute becomes conforming for any embedded element of role img.

Risks

• That implementation don't add support: Longdesc has historically only been allowed on frame iframe and img and, until further, it can only be expected to work on those elements. Whether any AT or any UA — by accident — already support @longdesc on more than img and the frame elements, has not been checked.
• What about a future @aria-describedAT? Answer: By gearing @longdesc towards image descriptions, the role of aria-describedAT is diminished - it would be left for other special cases such as ASCII art, ’table art’, CSS images and so on: @longdesc definitely has a role to play together with role=img in those use cases/situations.