- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 15 Sep 2010 19:00:21 +0200
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, David Singer <singer@apple.com>
Charles McCathieNevile, Fri, 13 Aug 2010 06:15:13 +0800: > It may be the case that a future version of ARIA can change this. > However, this boils down to having exactly the same attribute, with a > new name, available on more elements, in some unspecified future when > ARIA 2 is ready. I believe I have new info w.r.t. what ARIA 1 or 2 eventually needs to do. [*] [*] http://lists.w3.org/Archives/Public/wai-xtech/2010Sep/0031 As long as the focus is only elements with role="img", then is not so much that ARIA needs "exactly the same attribute, with a new name". It is rather the problem that ARIA's role="img" model doesn't fully implement the HTML's <img> model: Since the <img> model includes @longdesc, role="img" should also allow a link inside inside role="img" elements. But currently all children of a role="img" is treated as presentational, with the additinoal requirement that AT SHOULD NOT reveal them. Also, note that elements referred to with aria-labelledby or aria-describedby, are presented to the user as a text string, and not as mark-up. Thus if e.g. aria-descirbedby points to <a id=link href=*>link text</a> element, then all that happens is that the user is served the textual content as a label/description. I.e. the user doesn't get access to the link as a link. For example, role="img" causes the ASCII art in the example coide in HTML5, not presented to ARIA supporting AT. [*] [*] http://dev.w3.org/html5/spec/content-models#annotations-for-assistive-technology-products-aria The only thing that is presented, is the text content inside the label. Adding a link inside the label, would not make the link available to AT users. But if ARIA's role="img" would permit one link as child, for example a link with rel="longdesc", and treat it as a link and not as a text string, then the @longdesc use case would would be possible to solve via ARIA. Example: <figure role="img" aria-labelledby="fish-caption"> <pre> o .'`/ ' / ( O .-'` ` `'-._ .') _/ (o) '. .' / ) ))) >< < `\ |_\ _.' '. \ '-._ _ .-' '.) jgs `\__\ </pre> <a href="long-desc-url" rel="longdesc" >Link to long description</a> <figcaption id="fish-caption"> Joan G. Stark, "<cite>fish</cite>". October 1997. ASCII on electrons. 28×8. </figcaption> </figure> NOTE: to me this is a STRONG argument in favor of keeping @longdesc - ARIA should simply fully implement the <img> model for the "img" role. The role="img" simply allows authors some flexibility in how they offer images. Thus, just as role="img" doesn't compete with <img>, the same way wouldn't a <a rel="longdesc"> compete with - instead they would support each others: the author would be able to choose between using @longdesc inside <img> or rel="longdesc" inside <elment role="img">. (Alternatively, instead of rel="longdesc", one could e.g. have a @aria-longdesc attribute.) In order for this to happen, two things must happen: @longdesc must be kept in HTML - so that the <img> model is maintained, and ARIA must change to accept a link inside a role="img". -- leif halvard silli
Received on Wednesday, 15 September 2010 17:00:56 UTC