Re: Marking up links to alternative versions of content

Sander Tekelenburg wrote:
> At 12:27 +0300 UTC, on 2007-07-30, Henri Sivonen wrote:
>> On Jul 30, 2007, at 03:32, Sander Tekelenburg wrote:
> [re: <>]
>>> I can consume both the text and the audio, but only deduce that 
>>> they're equivalents by consuming both. There is zero indication 
>>> that they are equivalents.
>> The simplest possible way of addressing this issue without needing 
>> any changes to HTML and without any new browser UI would be adding a 
>> sentence immediately after the links to slides and the audio and 
>> briefly state what information they provide that isn't on the 
>> transcript page.
> {frown} The point of the example was that the audio and text are equivalents. 
> If there'd be a need to explain what one contains that another does not, then 
> they are not equivalents.

I amended the text on that page by appending "of the following 
transcript" after the link to the audio recording. It now reads.

   "You may also download the presentation slides (PowerPoint) and
    audio recording (Ogg Vorbis) of the following transcript."

I believe that indicates, using natural language, that the audio and 
transcript are indeed equivalents.  I also added rel="alternate" to the 
link, though I'm not sure what real practical benefit (if any) that will 

> [1] No program could make use of that.
> - Not an indexing bot.

When discussing applications that can't determine the association of 
being alternatives from natural language, it's necessary to explain why 
it would be beneficial for that particular application to do so.

As far as an indexing bot is concerned, presumably for a search engine, 
is it not enough that it can determine a relationship between them 
(based on the presence of the link), even if it doesn't know exactly 
what kind of relationship?

If, for example, a search engine were looking for audio files related to 
a particular topic, it's highly likely that it would consider the 
context of the pages in which it was linked or embedded.  This would be 
analogous to an image search.  The search engine can't view images 
itself to know what they are, but it considers the context in which they 
were found.

> - Not a tool that helps authors judge the universality/accessibility of their 
> document.

I'm not sure how useful a such a tool would really be in this case. 
Consider the alt attribute for images.  A tool can only tell you if it 
is or is not present.  It can't tell you whether or not the alternative 
text provided is indeed appropriate for the image.

So even if there was a way to markup an explicit association between 
alternatives, the tool could only tell you that the alternative is 
present.  It can't tell you anything about the quality of that 
alternative.  So while there may be some benefit to having the tool say 
yes, an alternative has been provided.  That in itself doesn't really 
tell you that much about the overall accessibility.

> - Not an authoring tool that needs to help the author to not mess up what a 
> previous author carefully added to try to help certain accessibility 
> situations.

Are there any tools that can do that reliably for existing embedded 
content, or any other type of association?

For example, an author could move a form control to a different location 
on the page.  Are there any authoring tools that let the user know 
they've forgotten to move the label with it?  In theory, that sounds 
somewhat useful, but is it possible to implement in a practical and 
usable way?

> [2] Considering humans: what you suggest provides far less usability than 
> explicit markup,  because without explicit markup a UA cannot provide
> consistency across sites.

I'm not sure exactly what you mean by "consistency across sites" in this 
context.  So I don't understand what the problem is, why it is a real 
problem, nor whether the problem would really be solved if explicit 
markup were available.  To answer that, we need to define exactly what 
should be consistent and how, and then look at lots of example sites to 
see if the current inconsistency is really a problem for users.  I don't 
know if it is or isn't, but I would like to find out.

> [3] Considering how non-explicitness doesn't address certain specific 
> accessibility situations. I believe Gregory already laid those out earlier.

Yes, he gave a useful account of the accessibility problems with the way 
YouTube has been built, and also of using a screen reader with forms in 
a table, and the importance of fieldset, legend and label.

In my opinion, although this is slightly off topic for this thread, 
screen readers need to do a lot more to improve the way they handle 
forms in tables.  Users shouldn't have to switch between table mode and 
forms mode just to understand such a form.  In particular, forms mode 
should make use of the table structure instead of relying on just labels 
and legends.

But anyway, perhaps the question is, what is the simplest way to express 
an association that a tool can understand?  Ben Boyle already described 
in this thread how HTML5's sectioning elements are useful grouping 
related content and Karl listed a few other methods of explicit 
association.  So perhaps we can look at what we've already got and see 
how we can put it together for our purposes.

This is what we've got, and what I think may be useful in this situation:

* <section> or <article>
* <aside>
* <figure> and <legend>
* rel=alternate and the proposed rel=longdesc

Here's an example:

   <h1>Movie Title</h1>
     <video src="movie">
       <a href="movie">Download the movie</a>
     <legend>Brief description or caption.</legend>
     <p>Metadata for the video (author, description, tags, etc.)</p>
     <p><a href="transcript" rel="alternate">Transcript</a></a>

Note: That example kind of misuses the alternate relationship, since 
it's currently defined to represent the alternative for the entire 
document, and not the alternative of the article or section it is in. 
Perhaps, longdesc would be a better value.

Lachlan Hunt

Received on Tuesday, 31 July 2007 06:52:59 UTC