- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Fri, 21 Sep 2012 04:34:43 +0200
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Hello A11Y TF. This new direction opens up a possibility for two conformance levels w.r.t longdesc use. And, inspired by Janina's identification of longdesc as fully functional in certain restricted corners of the web, I would therefore like to propose the following way forward: 1) We define a long descriptions spec as an extension spec, where the attribute should probably be allowed on all elements. 2. We reach FPWD status fast, to allow the attribute to be validated: http://lists.w3.org/Archives/Public/public-html/2012Sep/0284 2) We try to get a subset of that spec into the main HTML5 spec. We should definitely start with an initial round where we ask for input from vendors. However, if we end up picking the 'longdesc' name (which I think we should absolutely not rule out) and perhaps regardless of the name, I'd like to propose to aim for the following differences between the extension spec and the main spec: A) The extension spec should allow full URLs inside @longdesc B) The main spec should only allow hash names inside @longdesc For my initial reasoning for this separation, see my reply to Sam.[1] But to sum up, then, to only allow hash names in the main spec, would: a. catch most of today's "use", where majority seems to be erroneous b. put a heavy validation barrier on tools that auto-inserts the attribute. (A very high error percent is caused by them.) c. make it more difficult for authors to fake/misuse @longdesc. c. That hash names requires the description to be reachable from within the page, has a number of advantages, such as * makes it seem more similar to @usemap, which authors know better * less risk for link rot * easier to offer support to browsers without longdesc support * hopefully more eatable for the sceptic HTMLwg members. e. while it requires an extra skill set to chose another validation scheme (if one wants to use full URLs), it is a much lower barrier than learning to use another long description technique. As I told Sam[1], it is not reasonable to conclude that the massive misuse is caused by A11Y minded authors. Rather, that misuse is caused by more or less blatant misuse (due to the lack of extensibility in XHTML1/HTML4 *or* automatic tools that got it wrong). However, it seems unavoidable to not do *something* with that problem. That something could be to pick a new name. The main advantage of this would be a) less "baggage" and b) farewell to the bad code (as support for @longdesc dwindles in tools). There is also the 'half way', (to which I think I got a 'no', from Laura) to make @longdesc valid when/if it is combined with the new - to be named - @duck-soup attribute. However, this solution would result in 3 somewhat similar attributes: @longdesc, @duck-soup and - at some point - @aria-describedAT. Once one take those negatives in, then hash name seems like the only *other* limitation we can pick. It is, I think, a price we should consider to pay. The drawback I see is that it is more difficult to use @longdesc to point to in-page resource compared with making it point to another page. It is simple, but it might not work well in all implementations - I don't know. However, as there is a easy opt out (use another validator scheme) and as we don't need to require that all Web authors should be vanilla users - the can be experts, I think - again, that this might be a prince worth considering. [1] http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0423 -- leif halvard silli
Received on Friday, 21 September 2012 02:35:14 UTC