- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Thu, 04 Sep 2008 23:59:56 +0200
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Dave Singer <singer@apple.com>, public-html@w3.org, W3C WAI-XTECH <wai-xtech@w3.org>
-www-style, because this is no longer relevant to CSS Benjamin Hawkes-Lewis wrote: > Lachlan Hunt wrote: >> The longdesc attribute is not included for the img element. It has >> been clearly demonstrated in past discussions that it is a complete >> failure in practice > > It's not clear to everyone. :) I still think the evidence tells you > infinitely more about the dire effects of bad implementations on > authoring habits than the merits of programmatically determinable > associations (such as rapid non-linear navigation and easy content > extraction). What makes you think browsers will be able to find and implement a suitable and usable UI for allowing people to access the long description for a video via a longdesc attribute, any better than they did for img? Also consider that many of the examples presented in previous discussions that used longdesc in a reasonable way, also redundantly included an ordinary link alongside the image. Looking at the prior usability studies for the img longdesc attribute, there are several things should be noted: http://www.cfit.ie/html5_video/final/Longdesc_IDC.wmv 1. It can be clearly seen in the video that the user is infact activating the link following the image to get to the description, rather than using the longdesc attribute itself. 2. Most of the video is talking about the usability of the long description, rather than the usability of the actual longdesc attribute. 3. Near the end of the video, the user is talking about how long descriptions can be made more mainstream by making them useful to even sighted people in different situations. 4. The study was contaminated by the fact that the user was explicitly told the test was about long descriptions and how to access them, thus not providing any information at all about the usability of the mechanisms used to access the description. One example he gives is a mobile phone user with limited bandwidth who might disable images, and find it useful to be able to access the long description. Realistically, for a mobile phone user to access a long description, considering possible UIs, it's more likely that a regular link will be significantly more useful almost any conceivable UI that could be implemented for the longdesc attribute itself. Similarly, In these videos, they talk about the problems of using "[D]" as link text. But he still activates the D-link instead of using the longdesc attribute. http://www.cfit.ie/html5_video/final/Longdesc_BoxModel.wmv http://www.cfit.ie/html5_video/final/Longdesc_Node.wmv http://www.cfit.ie/html5_video/final/Longdesc_french.wmv A better usability study that would answer the question: Is the longdesc attribute is sufficiently discoverable by people using assistive technology, do they actually make use of it in the real world? Gather 2 separate groups of users using assistive techology for the study. For the first group: 1. Present the users with some pages containing images that have long descriptions, linked to only by the longdesc attribute. 2. Ask the user to obtain information about the images by navigating the pages. 3. For each image, ask the user questions about the images, including ones that they could only successfully answer after having read the long descriptions. The user could be made aware of what these questions were beforehand so they know what information to look for. To ensure that the test is as realistic as possible, the users should not be explicitly told that the longdesc attributes are there, nor that they need to activate them, since they certainly wouldn't have anyone there to tell them that in practice. For the second group, repeat test using plain text links to the long descriptions instead of the longdesc attribute. The previous study shows that using "[D]" may not be ideal link text, but there are other alternatives that could be tested as well, such as "description" or making the image itself a link. That result of this should then irrefutably reveal whether or not longdesc is at all useful. My hypothesis is that group 2 will access the long descriptions more than those in group 1 and thus answer the questions more successfully. If this hypothesis turns out to be true, then it demonstrates that the longdesc attribute is ineffective and that plain text links are more useful. >> and pursuing it as a solution for video is, IMO, a waste of time. >> Plus, I have already explained why any sort of long description, >> whether it be a transcript, full text alternative, or whatever else, >> is useful to more people than just those with accessibility needs. > > This is entirely true, but if anything it merely reinforces the benefits > of a programmatically determinable association between a video and its > transcript. There are ways to achieve implicit assocation, such as including the link to the transcript within the figure element. But even without that, there has been no significant evidence put forth, such as usability studies, to show that context alone is insufficient. For instance, if a user comes across a video and then in a subsequent, nearby paragraph, finds a link to a transcript, perhaps along with other video metadata, then it seems quite reasonable for the user to imply that it is the transcript for the video. In fact, here's an example of a video I found on CNN with associated transcript and article showing one way in which it can be done. http://edition.cnn.com/2008/POLITICS/09/03/palin.transcript/index.html >> Any links to a long description should be done using ordinary, visible >> links from within the surrounding content. > > Nothing stops longdesc (or a similar mechanism) and a visible link > pointing at the same location. But only an explicit mechanism can > provide a programmatically determinable association. It would be redundant. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Thursday, 4 September 2008 22:00:53 UTC