- From: Robert Burns <rob@robburns.com>
- Date: Thu, 6 Sep 2007 14:47:29 -0500
- To: public-html@w3.org
Hi Sander, On Sep 6, 2007, at 7:59 AM, Sander Tekelenburg wrote: > > At 14:03 +0200 UTC, on 2007-09-06, Olivier GENDRIN wrote: > >> On 9/6/07, Sander Tekelenburg <st@isoc.nl> wrote: > > [...] > >>> <img id="mergedcells" src="mergedcells.gif"> >>> <!-- anything or nothing --> >>> <alt for="mergedcells" title="short textual equivalent" >>> type="text/html">blah</alt> >>> <alt for="mergedcells" title="long description" type="text/ >>> html>blah, >>> blah</alt> >>> <alt for="mergedcells" title="tabular equivalent" type="text/html"> >>> <table border="1" summary="This table gives some statistics about >>> fruit >>> flies: average height and weight, and percentage with red eyes >>> (for both >>> males and females)."> >>> <caption><em>A test table with merged cells</em></caption> >>> <tr><th rowspan="2"><th colspan="2">Average >>> <th rowspan="2">Red<br>eyes >>> <tr><th>height<th>weight >>> <tr><th>Males<td>1.9<td>0.003<td>40% >>> <tr><th>Females<td>1.7<td>0.002<td>43% >>> </table> >>> </alt> >> >> Ok, I understand better what you meant. But in that case, I wish that >> your 3 titles where replaced by an attribute that would said : >> 'alternative', 'short description', 'long description' (@role ?). > > I don't think @title needs to be removed, even if predefined values > would be > added thropugh @role. @title might then be less necessary, but > might still be > useful, right? > > As to predefined values itself: I can see that such a thing might > be useful. > I'm trying to hold it off though, because I suspect that there is > no limit to > the sort of equivalents authors might want to provide. It doesn't seem > realistic to me that we can think ahead of descriptive terms that > will cover > all situations. So even we we define some generic predefined values > like > "short", "long", "audio", "captioned video", etc. we would still > have to > allow authors to use some non-predefined value: "table", "slide", > "pdf", > ".doc", "x", "y", "z". I do not think 'long' or 'short' is very useful.. Most of these others examples fall into the 'type' or potentially 'role' categories. > Note that in the <alt> proposal, @type is required already, and UAs > are > required to make that available to users, preferably translated into a > user-friendly form. > > I haven't yet given much thought to the specifics if MIME types in > this > context though. Possibly not all MIME types will be indicative > enough. Any > thoughts on that, anyone? > > Clearly audio/ogg, audio/mpg, audio/mp3, etc. would allow the UA to > indicate > that the equivalent is aural. But does the same apply to vague > container > formats such as .avi and .mov? > > What can probably not be indicated through @type is something like a > captioned video. Can we think of more such cases? (The more there > are, the > more important it gets that authors provide useful @titles, which > they might > get wrong, which would increase the need for something like @role.) .mov and .avi are not mediat types; they are filename extensions. All media types are going to begin with either text/, audio/, video/', application/ etc. The media types are not only insufficient to convey what accessibility information may be encoded in the type, but also they do not convey the codec used. The @role attribute would be useful these sorts of information. The title could be used as a last tier attribute to distinguish further between alternates that shared the same @type and @role.
Received on Thursday, 6 September 2007 19:47:49 UTC