W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2010

Re: Proof of growth of acceptance/implementation - longdesc

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 22 Sep 2010 10:14:32 +0200
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, John Foliot <jfoliot@stanford.edu>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>
Message-ID: <20100922101432005101.ce662b22@xn--mlform-iua.no>
Leif Halvard Silli, Wed, 22 Sep 2010 05:13:25 +0200:
> Leif Halvard Silli, Wed, 22 Sep 2010 03:08:18 +0200:
>> Leif Halvard Silli, Wed, 22 Sep 2010 01:45:20 +0200:
>> 
>>> Laura, here are some info which I believe you haven't listed in your 
>>> research page:

Laura, I continue to list NEW INFO that should be taken up in a 
re-consideration of the issue - hope that is OK. I will in this letter 
concentrate on ARIA.

Sam, should you happen to agree that some of the over 13 points I have 
presented so far, are news, compared with the situation when the 
Decision was made, then I don't mind hearing it - though work will 
continue regardless. 

Why ARIA is not a replacement:

10) @aria-describedby doesn't technically meet the requirements.
    During the debate and in the Decision, aria-describedby is 
mentioned as alternative. E.g. staunch ARIA propagator Jonas pointed to 
examples like this: 
		<img src=* alt=* aria-describedby=anchor >
		<a id=anchor href=link>Link to long description</a>. 
    And I believed and many with me, that this would be if not 
technically ideal, then at least possible. However, the recent debate 
on incorporation of ARIA in HTML5 has brought us to learn a few things:
   One: the above code will cause the AT to announce the text of the 
link, *without* announcing that it is link.
   Two: The anchor text will also be repeated: first its presented as a 
description. Thereafter it is treated as a link.
   Three: Thus, aria-describedby only fools us: it looks like it is 
creating a programmatic link between the <img> and the <a>. However, 
there is no such relationship, when it it comes to the link feature, as 
it is only the text of the link that is presented as long description. 
The only relationship between link and img is thus heuristic - meaning: 
one could skip the entire aria-describedby - that in fact probably be 
the beset thing to do, in the example above.

11) role=img is a failure 
    It allows neither @longdesc nor links within a caption.
    Like the name suggests, role=img indicates that the role is 
modelled after how the img element functions. The most illustrative 
feature of role=img in that regard, is the fact that the children of a 
role=img element are considered to be hidden, from AT's point of view. 
Only children which are pointed to via @aria-describedby or 
@aria-labelledby, will be presented to AT. So far so good. However, 
this - again - means that if the aria-labelledby or aria-describedby 
points to a child which contains a link, then the link will only be 
presented as a string of text and not as a link. Thus, the AT users 
will simply loose the entire link - since children of a role=img 
element are not presented at all, apart from their text, as described 
above.
   This is pretty ironic: it means that if a role=img points to a 
caption element inside the role=img element, then any link inside that 
caption, will not be presented as link. A link inside a caption - or 
even link as caption - is otherwise one of the methods that WCAG 
techniques mentions as a way for linking a link to an image.

12) We need both @longdesc and role=img to work.
    There thus seems to be a link between role=img's seeming lack of a 
way to connect a link to an image and the failure of ARIA to realize 
that @longdesc is part of the img elment.
    The solution to the problem with role=img, therefore looks to me to 
be to realize that ARIA has, in fact, _not_ implemented the img element 
model, as the img elemetn model in fact also includes @longdesc. If 
ARIA makes a change and takes in the _real_ img model, then role=img 
would give authors a choice between @longdesc and caption-with-a-link. 
Thus: the solution should come from HTML5 - and role=img should follow 
suite. Again I stress: aria-describedby and labelledby does permit a 
caption to contain a link. There is thus a conceptual link between 
allowing @longdesc in HTML5 and a role=img model which allows the 
author place a link inside a caption.

13) <a href=longdesc><img alt=foo src=*></a> is a failure.
    A link wrapper has been mentioned as a solution, especially when 
the image doesn't need to serve a double role as link and image. 
However, AT treat the above example in differing ways: At least 
VoiceOver will treat the above example simply as a link, where 'foo' is 
the link text. Others will present it as image.  In the bug about the 
default role for <img>, we already discuss what the best solution 
should be ... However, clearly: if the image is key content, then it is 
not all right to treat such images as link text. @longdesc here comes 
across as having clearer semantics  - its use makes it clear that the 
iamge is not a image link, but an image with a long description.
-- 
leif halvard silli
Received on Wednesday, 22 September 2010 08:15:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:14 UTC