Re: longdesc - beside the box

I think we need this for video, too. How about a @transcription
attribute on the <img> element (and <video> and <audio>) that contains
the link outright? Can be a link to some other element on the same
page or a different page altogether.

It would be displayed in text-only browsers instead of the media and
be keyboard focusable for AT users to be read out and followed.


On Mon, Apr 25, 2011 at 3:52 PM, Leif Halvard Silli
<> wrote:
> 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 07:34:25 UTC