Re: Drop longdesc, get aria-describedat?

I think we need to be careful before we start engineering what 
@longdesc2 will do. Firstly, we need to decide, is this for people with 
vision impairments (blind or low vision)? For people with cognitive 
impairments? For 'everyone'? I guess this comes under use cases (as per 
Lauras call for volunteers).

While, 'everyone' sounds great, and fits into the rather nebulous notion 
of 'Universal Design' that the HTML5 wg has. If we engineer something or 
VIPs, then the WG will say - "its not for everyone" and there will be a 
rabbit hole of discussion. If we design something for 'everyone' it may 
not work for VIPs and so on, which will result in a rabbit hole and also 
the creation of something that just doesn't really pass muster.

I am not saying UD is nebulous but in my experience what it is (and 
isn't) may be in the minds of some people in the WG. Anyway, I say this 
because if we don't clearly articulate what this @longdesc2 is early on, 
we will be back at square one having the same conversion in ~ 8 years.

I am quite happy with @longdesc2 quite simply being a an accessible long 
descriptor for blind users. That for me, should be the start. We could 
then 'progessively enhance' it for other use cases, but that should be 
the default.

I also have thoughts on the user experience (that I have posted many 
times) where if there could be a way that the contents were 'pre-loaded' 
or 'buffered' by AT and then called at the press of a key. Also I think 
the content should have the ability to be structured and navigable by 
AT. A specific bespoke '@longdesc hyperlink', may do this. This could be 
like a 'background URL' which has some of the functionality of an URL 
but does actually load visually in the browser but whose contents are 
buffered in the OSM that the Screen reader builds, or ideally loaded in 
the DOM.

Anyway, I would rather be explicit about what it supposed to do 
(actually clearly defining what it is _not_ may be more useful at this 
stage) to avoid fuzziness in its inception and realisation.



Received on Friday, 16 March 2012 08:59:52 UTC