Re: Is longdesc a good solution? (was: Acessibility of <audio> and <video>)

James Craig 2008-09-08 02.43:

> Leif Halvard Silli wrote:
> 
>> Since you used the word "full data set", I guess the spreadsheet will 
>> not be a textual equivalent of the chart, but rather an augmented - 
>> full - version of the background material.
> 
> You continue to make assumptions about the intention of my hypothetical 
> example.  I specifically said aria-describedby provides equivalent, not 

> identical functionality of longdesc.


If @longdesc is meant to lead to an exact, long, description (in 
HTML) of the graphic, while aria-describedy means that it can also 
contain "other interesting background material", then the question 
becomes: Is it of value for the user to know what he gets, or not?

 
>> If so, then it does IMHO not fullfill the role of a @longdesc 
>> resource, since the @longdesc URI should merely have contained a 
>> textual variant of the Chart. (@longdesc = "long @alt".)
> 
> I grow weary of this exchange. You overlooked the entire point of the 
> hypothesis to nitpick on details of little consequence. Nothing in the 


Because I think it is of enough consequense. I am not unaffected 
by Ians demand for a clear description of what @longdesc is 
supposed to solve.

> definition for @longdesc says it has to link to a raw text resource 

> nor that it has to link to a resource that *only* includes the textual 
> variant of the chart. 


I'm sorry you was lead to read me so. Indeed, @longdesc points to 
a HTML resource. I've never meant to give another impression. By 
linking @longdesc to @alt, I only meant to emphasize that we 
*know* what problem @longdesc is supposed to solve. It is not 
something which can be used to add "other interesting stuff, while 
we are at it", such a full data set in addition to a HTML version 
of the chart. (Any extra material must at last be well labelled.)

> As you keep repeating, it's just a URI. I'd argue 
> that a URI to an HTML version of the long description plus a table of 
> the full data set is more useful than a URI to just the long 
> description. 


Perhaps I was misreading, but I read your example to say that the 
rel=longdesc link pointed to a page which only had a full data set 
  table - but not any HTML table of the shorter chart at all. I am 
glad I was wrong there.

However, this still demonstrates what I had in mind: For majority 
users, it is not interesting enough to be offered a link to a html 
version of the chart they have already read, unless they are 
interested in copying the data or something. And I think that this 
is also why you felt you had to "spice up" your page with both a 
short table and a full data set table: You were unable to explain 
to yourself and to your potential users why you should provide a 
regular link to a page which only contained a HTML version of the 
chart they had allready seen.

However, here is an related problem that I see:

I have advocated that the @longdesc resource could be kept in the 
same page. What if the page contains several @longdesc resources? 
I think it could very easily happen that the user first reads the 
first @longdesc resourse, and without noticing it, starts to read 
the next one, without noticing it, unless we solve that problem. 
USers needs to quickly be able to tell when they finished reading 
the @longdesc, so they can go back to reading the main article.

Going back to your combined HTML Chart + Full Data Set page, 
again, provided we can separate the longdesc resource and the 
dataseet resource well, we could use @longdesc to point to the 
Chart Table, and the regular link to point to the Full Set:

<div role=img aria-labelledby=myImage aria-describedby=aLongDesc >
     <img id=myImage src=img.png
          alt="Chart showing Candidate X's 12% lead."
          LONGDESC=fullData.html#CHART-TABLE
          src=src >
     <a id=aLongDesc href=fullData.html#DATASET >
     Spreadsheet including full data set referenced in this chart.
     </a></div>

> In the same spirit of universal design that allows access 
> to everyone, I'd argue that showing a visible link to that long 
> description resource (as in the code sample) is better than burying that 
> URI in the longdesc attribute where almost no one can get at it.


In your example, the assumption that the @longdesc would be less 
acessible comes at a cost: AT users would want a fallback for the 
Chart. Instead offering them a presice @longdesc link to the chart 
table, you gave both them and the majority users a page which 
contained both the chart and the full dataset.

Regarding the technical side, it doesn't become more true just 
because you repeat it often. The real, undercommunicated fact, is 
that it simple to use JavaScript to let majority UAs follow 
@longdesc URIs.

Of course, it ought to be so that UAs by default let users open 
@longdesc URIs easily. But if we only can get the message, with 
the right idea, out, it should also be quite doable to get the 
opensource JavaScript libraries to help us towards the goal.
-- 
leif halvard silli

Received on Monday, 8 September 2008 03:36:29 UTC