- From: Joshue O Connor <joshue.oconnor@cfit.ie>
- Date: Fri, 16 Mar 2012 08:59:01 +0000
- To: Charles McCathieNevile <chaals@opera.com>
- CC: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, John Foliot <john@foliot.ca>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, RichardSchwerdtfeger <schwer@us.ibm.com>, W3C WAI-XTECH <wai-xtech@w3.org>, HTMLAccessibility Task Force <public-html-a11y@w3.org>
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. Cheers Josh
Received on Friday, 16 March 2012 08:59:48 UTC