- From: Joshue O Connor <joshue.oconnor@cfit.ie>
- Date: Fri, 06 Apr 2012 08:33:52 +0100
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: John Foliot <john@foliot.ca>, David Singer <singer@apple.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Silvia Pfeiffer wrote: [...] >> I would also (and I don't mean to single Silvia out here or anything but I >> am just interested in the general issue). I want to see clear use cases. > > Sure. > > In my understanding, the one long description that we link to the > video element (or any other element) is a full text replacement for > the element primarily for those who cannot consume the element (i.e. > accessibility users), but also able to be consumed by anyone else. Yes. This is the original goal of the @longdesc and should still be an explicit goal of 'shiney new thing'. >The > main target, however, is the accessibility users - that other needs > are satisfied with the same text is only a side effect. Total +1. > For example: let's assume a deaf-blind user A and a sighted and > hearing user B. A cannot watch a video that is embedded in a page. > However, the Web developer makes available a text document that > contains a full description of the video and links it to the video, so > that a braille reader will be able to give user A the same experience > as user B, if user B was to watch the video. Now, as it turns out, > user B is in the office and not able to watch the video. But because > we make the full description available to sighted users, too, B can > follow the link and read the document instead of watching the video. Yes, it it interesting that the @longdesc is tied to 'link behaviour'. For me, I'm not sure it should 'always' be a hyperlink, I think we need to talk with AT vendors about ways to engineer a design pattern for the @longdesc or 'shiney new thing' that improves the current model. Or hides a hard URL when not needed, that could be a simpler solution. Any, I don't mean to digress I agree with you but do thing that whether the @longdesc should be revealed to the user as a hard URL should be on a case by case basis. > Both user A and B are able to "scan" the document to their needs and > abilities. Both are able to talk about the video to a sighted and > hearing user C, who has actually watched the video, since all of them > have essentially received the same experience. Excellent. > This is how I envisage the long description to work and this is why I > don't see a difference between the document that the long description > should link to for a video and a transcript (where transcript is > defined as more inclusive than just the dialog). Sounds good to me. Again, to make this work we need clear use cases and to understand usage patterns and behaviours. Finally, we shouldn't forget that the primary use case if people with disabilities - anything else is just an 'extra' IMO. Cheers Josh
Received on Friday, 6 April 2012 07:34:22 UTC