longdesc - beside the box

Jonas asked for thinking outside the box. I note:

* We want images with longdesc link to be keyboard focusable. 
* There is an idea that it img is not the only elements that could need 
a long desc link.

So what about a global attribute which can point to a anchor element 
that acts as description link?

   Working name: @describedby (without aria- prefix). 

(Probably, another name than 'describedby' is better, to unconfuse its 
functionality from ARIA-describedby. For example: @desclink.)

Title of the entire concept: non-interactive single-link image map. 
(That is: non-interactive per HTML5's definition.)

Example:

<img id=image describedby=link alt="Lorem ipsum" src=i >
  <a id=link href=page#frag aria-labelledby=image ></a>
  <!--Without extra styling of some kind, this link
      is completely hidden for sighted users.
      And yet, it works fine for ARIA supporting 
      AT users. -->

The purpose of making @describedby (or what you would call it) a 
non-ARIA attribute is that it is supposed to work also for non-AT 
users. At the same time, ARIA AT can read the relationship and use it 
to achieve the same result.

The idea is that for example iCab, which supports @longdesc, can react 
to the img element in the above example in the exact same way as it 
does for img@longdesc now: by displaying a context-menu and by using a 
special cursor style to signal the presence of a long description link.

When it comes to keyboard focus, then whether it has any better 
potential than @longdesc has, is important to find out. To be perfect, 
the keyboard focus should "happen" on the element with the @describedby 
attribute - it should not "happen" on the link. OTOH, a link *is* 
keyboard focusable. However, in Webkit and Opera, it seems that a link 
which lacks link text is not focusable. While in Firefox it is 
focusable. I don't know about IE. The Opera and Webkit behaviour can 
help avoid that the link is presented twice.

Note that it is not always possible, for a global @describedby 
attribute, to be replaced by a link that wraps around the described 
element itself. For instance, if the described element itself contains 
a link - then it is invalid to wrap another link around it. And, for 
that reason, it seems that there is a use case for allowing 
@describedby to point to a link with link text, as well. (Because, 
otherwise, we would land in a situation were we added both a visible 
link - for all - and a invisible link for the purpose of programmatic 
association, for those that need that.) 

A question is whether AT can - or should - avoid to present such links 
twice. It seems that if the link *has* link text, then it should be 
presented twice. E.g a visible link might be reused as a long 
description link. But if the there is no link text, then it makes not 
sense to read it twice.

Back-compat story: If a link without link text is placed nearby the 
image/element it describes, then even ARIA enabled AT without support 
for @describedby will read that link. For other users, they can make 
such linsk visible via CSS.

Steve, Laura, Jonas - what do you think?
-- 
leif halvard silli

Received on Monday, 25 April 2011 05:53:04 UTC