- From: Sander Tekelenburg <st@isoc.nl>
- Date: Sat, 28 Jul 2007 07:55:14 +0200
- To: public-html@w3.org
At 12:53 +1000 UTC, on 2007-07-28, Lachlan Hunt wrote: > Gregory J. Rosmaita wrote: [...] >> no one is looking for a one-size-fits-all solution, as >> that runs counter to the whole concept of accessibility, > > Sander was suggesting that a full text alternative for video was a good > solution because it addressed various accessibility issues and technical > limitations. Not "good" or even best in specific cases. (I believe the english term I'm struggling to find may be "lowest common denominator") I was saying that as far as I can see it is the only sort of fallback that can work when nothing 'better' can (and that therefore it needs to be built into HTML). Anything more rich, such as captioned video, is obviously much better for certain specific situations, but it's impossible to have the ideal rich fallback for all possible situations. It *is* possible to have a basic fallback for all possible situations, while still allowing for richer fallback. <object data=movie> <object data=captionedmovie> marked up textual fallback </object> </object> Btw, it's clear that this structure would be a problem when you also want to provide an audio-only equivalent. The user would be dependant on the author deciding which should take precedence -- the captioned movie or the audio-only. That confirms the idea that Gregory and Chaals have already voiced that UAs need to provide access to all equivalents. The UA should (be configured to) use a certain default fallback algorithm, but should allow the user access to all equivalents (which of course means making those equivalents discoverable). [...] > bandwidth limitation, for example, is not an accessibility issue. Again depends on your dictionary. When bandwidth restrictions prohibit you from accessing a resource, you have no access. A textual equivalent is likelt to be accessible then still. Seriously, I'm not playing word games. The problem with the hi-jacked definition of "accessibility" is that all too often it means "accessible to my special interest group". So depending on who you talk to, the meaning is something else. That's why we have 'accessibility experts' advicing web publishers to use certain colours, contrasts, font sizes, javascript-dependant custom font-size menus, "menu must be at the top, preceded by 'Skip to content' link", etc. So what does "accessibility" mean, if it does not mean "the possibility to access x"? The reason I go on about this is that if we look at "accessibility" from the regular dictionary meaning point of view, it *is* one general thing: provide authors with the means to make content available to all users, regardless of their browsing environment. Again, that's not at all to say that specialised equivalents (such as captioned video) should not exist, be developed, be used. Just that looking only at individual cases cannot possibly lead to a generally accessible Web. [...] > For the video example, [...] For example, there a couple of > possible solutions: > > * Providing an ordinary link to the description alongside the video > pro: already possible and easy to do. > pro: makes it available to anyone who wants it, not just those with > assistive technology that exposes it. > con: ? Another con is that this would be similar to the having @alt and an image's caption being the same, as we discussed earlier. Alternatives are to be chosen from, not to be presented as if they are complimentary. You don't want your alt text rendered next to the image. You want to provide/consume *either* one (at a time). > * Nesting the alternative content within the video. > pro: the content is semantically associated with the video pro: it can be marked up, unlike something like @alt. It can thus be made to 'look better' (which seems likely to be an incentive for authors to bother to try to provide a textual equivalent). pro: no special attribute needed to specify the semantic link with the video. > con: may not be readily available to anyone who wants it, only those > with assistive technology that exposes it. Why? You don't need Jaws to get access to an alternate. Your average GUI browser can provide access to @alt through some mechanism (IIRC Chaals suggested the contextual menu). We know of one general purpose GUI browser that for many years already provides users access to @longdesc without needing to be labeled "AT". -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>
Received on Saturday, 28 July 2007 06:01:32 UTC