- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 17 Jan 2011 22:35:04 +0100
- To: PFWG Public Comments <public-pfwg-comments@w3.org>
(I hope it is OK that I reply here, instead of using the online Web
form link.)
This is my reply to your Response on Comment 335:
(http://lists.w3.org/Archives/Public/public-pfwg-comments/2010OctDec/0018.html)
(A) Your response relates more to @longdesc's fate in HTML5 than it
relates to my critical remarks regarding "content model" of role="img"
in ARIA 1.0 LC. As such the remark dos not speak to my comment. I
would appreciate if my critical remarks were directly considered. In
that regard, the failure to have a HTML4-relevant role='img' model not
only impacts on <img> element with a @longdesc attribute, but also on
image maps (whether constructed with <img> or <object>), on objects
used as images (<object data=image.jpg >fallback</object>) as well on
any <foo role="img"> element - see letter (M) to (Q) below.
(B) The kind of response I was looking for was one that said something
along the following lines: An element with explicit role="link" and
which is pointed to via @aria-labelledby (or maybe a new
@aria-anchoredby attribute) would be treated as a link, also when it is
the child of an element with role="img".
(C) Thus, a transformation of @aria-describedby to allow it to take
URLs (as you say that you have agreed to *consider*), does not address
my request to alter the "content-model" of role='img' to incorporate
links.
(D) While it might me worthwile to extend the syntax and functionality
of @aria-describedby this way, such a thing is not an answer to the
question of the inner workings of elements of role="img" type.
(E) Despite that ARIA 1.0 LC says that the "img" role can be applied
to an element that act as, quote: "A container for a _collection of
elements_ that form an image", the 'img' role is obviously mimicing the
_void_ <img> element of HTML4. Thus, ARIA 1.0 LC offers us a 'img'
model where a void element, <img>, can be expressed via "normal",
non-void elements. This even extends to children. For example, if we
have
<foo role=img aria-label=child ><bar id=child >Lorem</bar></foo>
then the role of the @alt attribute has been "taken over" by the <bar
id=child > element.
(F) Thus, to say that @longdesc can be replaced by
@aria-describedby=URL - and nothing else, is similar to say that @alt
can be replaced by @aria-label - and nothing else. Fortunately, with
regard to @alt, role="img" also permits that the @alt attribute can be
replaced by designated child element(s) that is/are pointed out by
@aria-labelledby and/or @aria-describedby. And I am looking for a
similar way to point out description link(s).
(G) Hence, an *accurate* ARIA 1.0 role='img' replication of HTML4's
IMG element, would have incorporated that the @longdesc attribute
could be expressed as a normal anchor element.
Example 1:
<div role=img aria-labelledby=caption >
<a role=link href=description.html >Smiley face description</a>
:-)
<p id=caption >The smiling smiley is familiar to many.</p>
</div>
Example 2:
<div role=img aria-labelledby=caption >
<a role=link href=description.html >
<img src=big-smiley-image.jpeg alt="" >
</a>
<p id=caption >The smiling smiley is familiar to many.</p>
</div>
(H) Currently, the links in Example 1 and Example 2 under letter (G)
above, would simply be ignored by AT. Even if one gave them an @id and
pointed to them via @aria-labelledby, the link functionality of the
above anchor elements would remain hidden to AT.
(I) In an example like the one in (G), for the author to have to
repeat the very same URL of the anchor element in the @aria-describedby
attribute, is both cumbersome, unintuitive and risky - the @href of the
anchor and the @aria-describedby could easily get out of sync.
(J) Further, @aria-describedby is, unlike img@longdesc, a@href and
area@href, *not* an interactive feature, which the author can
choose to ignore or open. (Though, I grant you that I don't know
(ISSUE-411 is not open to non-members of of the PF) whether you plan
that URLs inside @aria-describedby should be accessed interactively.)
(K) It is fine that you support the @longdesc, but it would have been
a more thorough support to if you had, as you have for @alt,
incorporated @longdesc as "something" in the 'content-model' of
role=img. Failing to allow links (an not necessarily only a *single*
link) inside an element of role "img", the ARIA 1.0 LC failed to give
the HTML4 IMG model - and thereby @longdesc - its proper support. (In
that regard, it is is relevant to mention that the accessibility
community within the HTMLwg, lead by Steven Faulkner, is pressing hard
on the editor to get him to say that <img> defaults to role="img".)
(L) It is also notable that in the HTMLwg's debates about @longdesc,
the idea that @aria-describedby could point to an anchor element, which
in turn could point to a descripion link, was aired several times.
Clearly the proponents were not aware that such an anchor element would
be treated as pure text and not as a link, by AT. But, nevertheless,
this demonstrates how many members of the HTMLwg are of the opinion
that it would have been natural to be able to use "normal links" as way
to point to descriptions. This view is also expressed in the HTMLwg
Chairs' Decision on the @longdesc issue. Simply saying that such links
could solely and fully be handled by @aria-describedby, does not answer
that expectation.
(M) But the - I claim - simplistic content-model of role='img' is not
only a problem that impacts images with a @longdesc - it also relates
to images that are image maps and as well as to the object element when
it is used as a image container.
(N) Image maps using the <img> element or the <object> element.
In addition to @longdesc, HTML image maps is an example of another
<img> related construct that ought to be compatible with ARIA's
role="img". The links inside an <map> element that is connected to an
<img>, are conceptually very simplar to a link within a <foo
role="img"> as well as to the @longdesc link inside an <img>. But,
alas, by default, some AT simply treats the @alt of for example
<img src=img.png alt="Lorem" usemap="#map" >
as none-existing - it is ignored. Instead, only the content of the <map
name="map"> element, is used as "image content". This is the case for
VoiceOver used together with Safari and Opera. (Note: tested on Mac OS
X 10.5/Leopard.)
Adding role="img" causes at least VoiceOver (Mac OS X 10.5) to ignore
the <img> as an image map and instead treats it as a regular image
element. Thus, again, the problem is that a link that, conceputally,
occurs inside an element of role="img" element, does not fit intio
whether VoiceOver nor ARIA 1.0 LC.
<object> elements that act as image maps differs from <img> by
allowing that the <map> is placed inside the <object> instead of
outside it. This model is still part of HTML5. An <object
data=image.jpg > defaults to having role='img'. Hence, it is obviuos
that a content-model for role='img' which does not take that into
account that there could be a link (anchor or area link) inside the
<object>, does not speak to reality.
(P) Note that HTML4 says, quote: "When the image has an associated
image map, this attribute should provide information about the image
map's contents. This is particularly important for server-side image
maps." It is thus quite ironic that, when an image act as an image map,
then - typically - neither @longdesc nor the @alt text is given heeed
to by user agents. (In the moment, I can say for sure that all Webkit
based browsers as well as Opera simplly ignores the @alt when the <img>
is an image map.)
(Q) <object> used instead of <img>.
Jason White suggested to me that in place of @longdesc, one could use
use an <object> element and place a link inside the fallback of the
object element. And, yes, technically - or should I say: in theory -
one could. But there are lots fo problems. Firstly, lots of AT
apparently have problems with object - they don't read the fallback of
an contstruct such as this, to the user:
<object data=image type="image/gif" ><a href=link >Fallback.</a>
</object>
E.g. VoiceOver fails to do read this, simply because VoiceOver treats
any <object> that it considers as an image container as having
role="img", thereby hiding the fallback from the user. OTOH, if one
staffs that <object> with a little ARIA, then the AT should read it.
And surely, VoiceOver does then read it aloud, however, the link
functionality is ignored by ARIA supporting AT, including VoiceOver:
<object role="img" id="img" aria-labelledby="img" data=img.gif
type="image/gif" ><a href=link >Fallback.</a></object>
(R) WORKAROUND - sort of.
FWIW, the following works as a workaround: In VoiceOver on Mac OS
X 10.5.8 it allows the author to place a link "inside" the image
(provided <map> is hidden from visual users). The reason why it works
might be firstly, because the <img> is not treated as image map and,
secondly, because while the failure to read the image as a image map
causes VoicOver to ignore the <area> element, VoiceOver instead reads
the anchor link. Thus, in reality, this is no different, from
VoiceOver's perspective, than an <img> followed by a link.
<img role="img" src="quote.gif" alt="Lorem ipsum." title=""
aria-labelledby="map" usemap="#map" />
<area href="longdesc.html" target="_blank" alt="Link to long
description" role="linK" coords="0,0,773,226" shape="rect" />
<a role="link" class="longdesc" id="ariaLink"
href="longdesc.html" rel="longdesc" target="_blank">
Press enter for long description.</a>
</map>
(S) SUMMARY:
I suggest to EITHER losen up on what Children Presentational=true
means, by saying that an <a role=link> child would be treated as a
link, when inside a role="img" elment. And/or to offer a way, such
as a new @aria-anchoredby attribute, to point to an element that
acts as description link. ARIA 1.0 should also give specify that
even elements acting as image maps should be treated as having
role="img" (or, at least, it should say that even for images
acting as image maps, the @alt and/or aria-* attributes should
be given heed to).
Details: I would prefer such links to not be treated as @longdesc links
unless the <a> or <area> also have a rel="longdesc". Because it is
clear, not least for image maps, that a link inside an image not always
is a longdesc link.
Oslo, 17th of January 2011
Leif Halvard Silli
> Comment 335: @longdesc implemented as ARIA construct
> Date: 2010-09-15
> Archived at:
>
http://lists.w3.org/Archives/Public/public-pfwg-comments/2010JulSep/0053.html
> Relates to: Accessible Rich Internet Applications (WAI-ARIA) 1.0 -
> img (role) <http://www.w3.org/TR/2010/WD-wai-aria-20100916/#img>
> Status: Alternate action taken
>
> -------------
> Your comment:
> -------------
> I hereby formally propose that role="img" permits a long description link
> inside. That is: there should be some way to make sure that a long
> description link inside a role="img" element, is presented to AT users as
> a link.
>
> One motiviation for this request is to allow @longdesc be implemented as
> a normal link. And I hope ARIA will explain how AT which already support
> @longdesc should treat @longdesc when they see a parallel long description
> link. (They should probably ignore the @longdesc and use the long
> description link instead.)
>
> Currently, ARIA requires AT to treat children of role="img" elements as
> presentational. And, even if you point to a link inside the role="img"
> elment via aria-labelledby, the link is only presented as a text string,
> without link features.
>
> The method I would propose is that the first link with a rel="longdesc"
> or aria-longdesc="true" attribute inside the role="img" element, is
> treated as a long description link and presented to the user user as a
> link.
>
> This idea was first described in the following letters, which I recommend
> to read for more detail:
>
> http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0030
> http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0031
> http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0429
> http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0033
>
> --------------------------------
> Response from the Working Group:
> --------------------------------
> ARIA today supports an aria-describedby by property intended for longer
> descriptions. The reason for this is platform accessibility APIs support
> short names (labels), descriptions descriptions, and relationships to long
> descriptions. Today, aria-describedby supports an id value as it was
> intended that the description relationship reference prose on the page that
> would also be readily available to users with cognitive impairments. Rather
> than introduce another attribute for longdesc the group has agreed to
> consider extending aria-describedby to also support a URL. We have opened
> ISSUE-411 to track this. If longdesc is removed from HTML 5 we will push
> for a fast track ARIA specification enhancement that expands
> aria-describedby to support this new feature.
>
> ----------------------------------------------------------------------
Received on Monday, 17 January 2011 21:35:40 UTC