- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Mon, 25 Apr 2011 07:52:35 +0200
- To: HTMLWG WG <public-html@w3.org>
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