- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 22 Mar 2012 19:13:15 +0100
- To: public-html-a11y@w3.org
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