- 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