- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Tue, 31 Jul 2007 16:52:37 +1000
- To: Sander Tekelenburg <st@isoc.nl>
- CC: public-html@w3.org
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: <http://lachy.id.au/dev/presentation/future-of-html/>]
>
>>> 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
achieve.
> [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:
<article>
<h1>Movie Title</h1>
<figure>
<video src="movie">
<a href="movie">Download the movie</a>
</video>
<legend>Brief description or caption.</legend>
</figure>
<aside>
<p>Metadata for the video (author, description, tags, etc.)</p>
<p><a href="transcript" rel="alternate">Transcript</a></a>
</aside>
</article>
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
http://lachy.id.au/
Received on Tuesday, 31 July 2007 06:52:59 UTC