W3C home > Mailing lists > Public > public-pfwg-comments@w3.org > January to March 2011

Comment 335, ARIA 1.0 LC (Was: Response to your comments on Accessible Rich Internet Applications (WAI-ARIA) 1.0)

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>
Message-ID: <20110117223504363409.a90cb283@xn--mlform-iua.no>
(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:

 (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 

 (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 
	<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>

  Example 2:

	<div role=img aria-labelledby=caption >
		<a role=link href=description.html >
		<img src=big-smiley-image.jpeg alt="" >
		<p id=caption >The smiling smiley is familiar to many.</p>

 (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>

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>

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: 
> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 January 2011 21:35:40 GMT