- 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