Warning:
This wiki has been archived and is now read-only.
ChangeProposals/LinkLongdescToRoleOfImg
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.
Contents
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.
- The
img
element is not HTML’s only method for including images. - 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.
- 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. Anobject
oriframe
might — similar to theimg
element — embed an image. If the author does addrole=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 roleimg
, 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 roleimg
, 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.
- 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
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:
- In Internet Explorer, then - to users - there is no difference between an image embedded with the
img
element and an image embedded via theobject
element: The user gets the same contextual menus and so on. By contrast, it seems like Safari does not provide the same menus. - For AT, if the
object
element embeds an image file via @data
, then AT of the screenreader type, typically handle the element as animg
element. Which means that they don't read the object element’s fallback content. And thus, for all intends and purposes, theobject
in this case is seen like animg
, except that there is no @alt
. - 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 roleimg
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.
- ASCII art: Technical descriptions, such as RFCs, specifications and so one, often provide descriptions in the form of ASCII art inside
- 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 apre
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 limitinglongdesc
to embedded content, and allowing the futurearia-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 isimg
, 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 ofimg
, authors might simply embed them via @src of theimg
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 theimg
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
- Implemenent the Details section of Laura’s proposal
- Define @
longdesc
as a global attribute for embedded elements in the HTML namespace, if the image has therole
attribute and its value isimg
. - 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 theimg
role.
- I have heard from Steve Faulkner that AT done have any specific problems with
- 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 thevideo
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.
- Weak objection: Yes, as long as it is meant solely for the poster image means that it could make sense to use @
- 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
- True. If the problem of discoverability can solved, then there is no principal reason to not allow @longdesc on any element of role
- Why not
SVG
andMATH
- 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 givenimg
role, then the link will become inaccessible to AT (unless — again — ISSUE-204 impacts on that).
- By default, these elements do not default to image role. Also, they - at least
Conformance Classes Changes
- The same as in Laura Carlson's CP.
- Except
svg
andmather
,t he @longdesc
attribute becomes conforming for any embedded element of roleimg
.
Risks
- That implementation don't add support: Longdesc has historically only been allowed on
frame
iframe
andimg
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 thanimg
and the frame elements, has not been checked. - What about a future @
aria-describedAT
? Answer: By gearing @longdesc
towards image descriptions, the role ofaria-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 withrole=img
in those use cases/situations.