W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2012

(unknown charset) Description link consensus

From: (unknown charset) Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Thu, 22 Mar 2012 19:13:15 +0100
To: (unknown charset) public-html-a11y@w3.org
Message-ID: <20120322191315186532.72922516@xn--mlform-iua.no>
The describeAT draft:

Rich and Steve's draft for describedAT was released after my CP to 
extend @longdesc to embedded elements with the role 'img'. Their draft 
could be a reason for me to back off my CP, and for us all to instead 
give full support to  Laura's CP to get @longdesc for the img element.

Camels to swallow: 

Some in the A11Y TF think @longdesc should be obsolete but conforming. 
Others want a two-step process where longdesc becomes valid for <img> 
first, and then extended to more elements. My own CP suggests to extend 
longdesc immediately, to embedded elements of role 'img'. The sweet 
spot - the compromise solution - seems to be to support Lauras CP and 
thus support @longdesc as fully conforming, and also not try to have 
any two-step process within HTML5. A way towards consensus, is to 
postpone the questions we can postpone, to HTML.next. May be one wants 
to reevaluate longdesc in HTMl.next or when ARIA1.1 is out. And also, 
possibly evaluate whether - in HTML5 - aria-describedAt should be valid 
on any element. But we don't need to decide this now. In fact, we can't.

Impact of describedAT:

On one side - the ARIA-describedAT draft, is a good step which will 
support Laura's @longdesc proposal - as it stands. That is: For the 
<img> element.  Also, by making longdesc specific to <img>, there might 
be a chance for deeper integration with that particular element - e.g 
as outlined in my comment on the Webkit bug: 
https://bugs.webkit.org/show_bug.cgi?id=10448#c6

On another side - the ARIA-describedAT draft does as well not encourage 
the extension of longdesc to more elements, for instance because it 
seems unlikely to me that we will get longdesc support for new elements 
any earlier than we get aria-describedBY support.

On the third side: If the two attributes effectively ends up as 
essentially the same feature , then, unless the two specs - HTML5's 
longdesc spec and ARIA 1.1's describedAt spec -  are aligned, then 
implementors might avoid implementing @longdesc and instead wait for 
the final word on aria-describedAT. I don't mind if the implementation 
of @longdesc takes color from the @desscribedAT implementation. But 
there are some important details that should be agreed upon.

Current feature differences:

A difference between Rich/Steve's draft and Laura's CP, is the latter 
emphasizes 'no visual encumbrance' whereas Rich/Steve say that there 
SHOULD be a visual indicator on [I think] the page. Perhaps the 
describedAT draft should leave it to the host language what to do by 
default? Or should @longdesc and @describedBY differ in that detail? 
This needs clarification.

Another difference is that longdesc is only used for embedded content - 
images, iframes and frames in HTML4, whereas describedAT applies to any 
content - even elements which typically do not have any context menu 
[typically only embedded content has context menus]. Perhaps the 
describedAT draft should say that it depends on the host language 
whether a contextual menu is shown?
-- 
Leif Halvard Silli
Received on Thursday, 22 March 2012 18:13:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:27 UTC