RE: Javascript alternatives not necessary?

We had this problem solved ages ago until some how the two
items I quessed about were removed.

*	supported in multiple, independently-developed
implementations of the browsers, user agents, and
assistive technologies.
*	supported across multiple operating system
platforms (i.e., Microsoft, Macintosh, or Unix - not
Win98/2000/XP)

When Jason and I originally proposed this we had the
requirement that the accessibility features must be
supported in at least one prior version of the AT being
supported.  That would mean that at this point, Flash, as
a good example, could be considered accessible if it were
supported on more than just Microsoft because it is now on
it's second version.  Flash Player 6 was the first version
that supposedly made Flash accessible.  Flash Player 7
should be doing that still.

Sorry to pick on Flash, but it is a good example.

Even with that I don't think Flash meets the requirements
of being accessible for the very point I've already made.
Put an audio file in the Flash presentation and a deaf
person doesn't know what it says.  They can't control it.
There are many other issues I could bring up.

SMIL is a standard that works across AT and operating
systems.  That would be accessible.

We need the requirements mentioned above back in the
guidelines.  Otherwise we will always have this problem.
We actually need it the way it was orginally.  I'm not
complaining that someone took Jason's and my work out, but
obviously no one paid attention to it and now we are in
the same situation we were two years ago when we added.

So, I propose we backup get those elements back in the
guidelines and then see how this text-alternative works
out.

Lee Roberts
http://www.roserockdesign.com
http://www.applepiecart.com

-----Original Message-----
From: w3c-wai-gl-request@w3.org
[mailto:w3c-wai-gl-request@w3.org] On Behalf Of Michael
Cooper
Sent: Thursday, July 22, 2004 10:21 AM
To: w3c-wai-gl@w3.org
Subject: RE: Javascript alternatives not necessary?


This thread has been illuminating because it's showing
that there are two separate issues which have been
confounded. Perhaps it will be useful to treat them
separately.

1) There is the issue of whether a text alternative for
non-text content should be required if that content itself
is accessible.

2) Then there is the question of how widely supported the
accessibility features of a non-text format must be before
the first question becomes relevant. 

The second question is a tangent off the first one, but
one we need to address. Somebody pointed out that as
technologies evolve, there will always be the situation
that there are new technologies that are not yet
universally supported, or whose accessibility features
aren't universally supported. So we need a stance on that
in the guidelines. Separately, we also need a position for
the case of non-text technologies that are in fact
universally supported. I will leave aside the argument of
which present-day technologies (if any) may fall into that
category - that is an issue we will have to wrestle with
in techniques but shouldn't impact the guidelines.

Here are the steps I think we should take:

A) I think members of the group will agree that non-text
technologies that are not accessible, whether for lack of
accessibility features or for lack of support for the
accessibility features on some os/browser/at combinations
require text alternatives. Mainly I'm just reiterating
that here, it's already in the guidelines, but if there's
disagreement about that here's a forum to raise it.

B) I propose that, if a non-text technology is accessible,
we not require text alternatives. I would be interested to
hear if there is disagreement with that. Otherwise I will
write up a more complete proposal around that and we can
discuss the merits more completely.

C) Then we need to struggle with a way the guidelines
describe the way of determining whether a particular
non-text technology fits into category A or B above. Some
have said that the technology and its accessibility
features must be supported in all Web browsers and AT
combinations before it is considered accessible. Others
have said that is an impossible standard, as the Web is
diverse and we can't control or even know about the
variety of user agents out there, and what we need is a
way of saying enough user agents support the technology
and its accessibility features that most users are
covered. One response to this is that "most" is not enough
and therefore proposal B above is a non-starter, and all
non-text technologies require text alternatives. That
brings us full circle to the question that started this
thread.

Perhaps it would be useful for people to provide their
opinions on each of those three steps separately. The
separate answers don't have to support each other; I would
consider it acceptable to say to B that you agree with the
principle, but agree in C that the principle can't be
activated and therefore B is meaningless. That's not the
only combination of answers of course, just an example of
one kind of useful even though internally inconsistent
response people might make.

I'm carefully steering clear of mentioning any example
technologies here.
The examples raised earlier sparked some of the discussion
that led here and was useful, but I'd like to avoid
getting caught up in particular technologies now as we try
to resolve this general issue.

Michael

Received on Thursday, 22 July 2004 13:31:55 UTC