Long descriptions spec - a basic idea

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