W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2004

RE: Javascript alternatives not necessary?

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Sat, 24 Jul 2004 23:15:32 -0500
To: "'Fentress, Robert'" <rfentres@vt.edu>, <w3c-wai-gl@w3.org>
Message-ID: <auto-000033980596@spamarrest.com>

Some comments....  

Marked GV:

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 

ITEM 1: ===========================================================
[quote - M Cooper]
-----Original Message-----
From:	Michael Cooper [mailto:michaelc@watchfire.com]

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

[quote - Fentress, Robert] 
Yes.  Well-phrased.

GV: How could content be accessible if not in text?   How do you render it
into braille for example for someone who is blind but does not hear well? 

GV:  Also, how do you change language level?  

ITEM 2:  ==========================================================
[quote - M Cooper]
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

[quote - Fentress, Robert] 
Yes.  That is also an issue.

Another is whether all non-text functionality can be represented adequately
by text alternatives.

GV: If it is truly impossible to create a text alternative then if the
person does the best job they can it is unlikely that someone will challenge
it.  The requirement is not that it be 'adequate' so they would pass if they
do the best they can.  For the vast majority this is not the problem. 

GV: Could you cite some examples?  It would be helpful here. 

GV: Not sure I understand the widely supported bit with regard to text. Text
is defined as Unicode.   Please elaborate on this.  Thx. 

SECTION 3:  ========================================================== 
[quote - M Cooper]
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.

[quote - Fentress, Robert] 
I think another issue is whether a necessary component of accessibility is
that content must be cross-platform, and, if so, to what degree?  Must it
work on Windows, Mac, and Linux?  How about Windows 3.1, Mac OS 7, 8, 9,
DOS, Amiga?  How about Pocket PC, Palm, and Blackberry?

Related to all this is defining at what point content should be treated as
an application and at what point should it be treated as web content.
Assumedly, an application program need not run on all platforms to be
considered accessible, but perhaps more is expected of web content. 

Are there different standards, in terms of cross-platform and cross-user
agent compatibility for web content that is general purpose versus web
content for an audience that registers to access specific content and
functionality after being informed of the limited subset of user
agents/platforms that are supported.  For instance, what if one registers
for a course that uses a particuar web application that only works on one or
two browsers or platforms, but for which there are assistive technologies
that make the content accessible to people with a wide variety of
disabilities.  What about browser-based Intranet applications designed to
only function on specifc platforms, which the organization has standardized
on.  Branches of the military have standardized on IE on a PC, for instance,
as a universal base for all of their browser-based applications.

GV:   I think we talked about this in terms of PUBLIC STANDARDS or
SPECIFICATIONS.  Technologies that are proprietary and do not have open
published standards were a problem.  Don't think we have come to a wording
and you are right - we don't have it in this version yet.  However the text
alternative is the fall back that makes it accessible. 

SECTION 4:  ==========================================================
[quote - M Cooper]
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.

[quote - Fentress, Robert] 
I only agree if (1) text alternatives can provide equivalent functionality
to what they are replacing, and perhaps (2) the non-text technology is not a
part of a web application and that web application does not allow assistive
technologies to access its content on a widely-supported platform (either
one which is supported by the particular organization the application was
designed for, or one which is ubiquitous in the larger community).  Perhaps
an application such as that layed out in (2) could be granted some sort of
diminished accessibility status, but I don't think this should preclude the
resource from claiming some sort of accessibility compliance.

GV:  Accessible applications is an interesting and challenging area.   As we
move to more and more 'always connected' situations we may have more and
more applications that are half on client and half on server.  What is "Web
content."  Do we have two types and two sets of rules?

SECTION 5:  ==========================================================
[quote - M Cooper]
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.

[quote - Fentress, Robert] 
Sounds good to me.

GV:  That is a major departure from our guidelines -- so if we are going to
do that it will take some discussion.  I can see the thinking -- but I don't
know how you are going to handle the "if it is accessible' criteria.

GV: By the way - if the text is accessible and is electronic in nature then
I think it might meet 1.1.    Have to discuss this. 

SECTION 6:  ==========================================================
[quote - M Cooper]
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.

[quote - Fentress, Robert] 
See the response to A, above.

GV: Yup. 

SECTION 7:  ========================================================== GV:
Good discussion.  Will be a good one for a face to fact or a special Telecon
devoted to it. 

GV: More posts from others ?   Not saying the same things -- but does anyone
have any concrete proposals?  

Thanks Mike, Rob. 

Received on Sunday, 25 July 2004 00:15:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:50 UTC