Re: conflation of issues or convergence of interests?

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