- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 7 Mar 2012 02:54:35 +0100
- To: Janina Sajka <janina@rednote.net>, Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: W3C WAI-XTECH <wai-xtech@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Janina, Richard - and the ARIA community. The F2F Minutes Extract on Action-970 says: [1] > rich: [ snip ] when we do describedat, will ask browsers for > a vehicle to render that location Question: Is there a chance that "we could do" @aria-describedat *now*? I am convinced that the chances for a amicable solution would increase greatly if one could move from talk to action with regard to @aria-describedat. > agreement in room: longdesc and describedat are preferable to this > because they're so very much simpler There are potential problems related to having both @longdesc and @aria-describedat: @longdesc as a HTML5 native feature, would be the HTML WG's domain. It is not clear to me, yet, what rules you plan with regard to @aria-describedat's permission point to for example sections that are hidden via aria-hidden=true. But what is certain is that @longdesc would be subject the rules that the HTMLwg decides also in this detail. Whereas the rules for aria-describedat, would be entirely in the hands of PF/the ARIA community. When we consider how difficult it seems to be to agree about how to @hidden relates to ARIA, it seems to me to it *could* be an advantage if we only had @aria-describedat instead of two attributes with potentially different rules. We could also view it tactically: The negativity towards @longdesc could - if the two attributes get linked in people' mind - spill over to @aria-describedat. Also, as long as neither @longdesc nor @aria-describedat are legal, then neither author or vendors are picking any of them up. [1] http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0004 -- Leif Halvard Silli
Received on Wednesday, 7 March 2012 01:55:12 UTC