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

RE: Javascript alternatives not necessary?

From: Fentress, Robert <rfentres@vt.edu>
Date: Mon, 26 Jul 2004 11:16:42 -0400
Message-ID: <E7BD4EDD62660F44922C0B11258FBE8F401234@fangorn.cc.vt.edu>
To: <w3c-wai-gl@w3.org>

My responses surrounded by <RAF>
--Robert Alexander Fentress

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]

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

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?

<RAF>You don't.  If JavaScript-based functionality cannot be replicated with a text alternative, you simply require the user access the resource with a JavaScript-enabled browser.  The content produced by the JavaScript-enabled browser must be accessible to those using assistive technologies.  It might be wise to require the inclusion of a <noscript> indicating that this resource requires Javascript, but there are instances where the functionality provided by the script simply cannot be replicated with a text alternative.</RAF>

GV:  Also, how do you change language level? 

<RAF>Sorry.  I'm not sure what you mean?  Could you be more specific?  Thanks.</RAF>


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
relevant.
[/quote]

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

Another is whether all non-text functionality can be represented adequately
by text alternatives.
[/quote]

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.

<RAF>The prescription that one must "provide equivalent information" implies to me that the text alternative be at least adequate.</RAF>

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

<RAF>Yes.  SCORM content requires JavaScript support in order to access the content as intended.  It is essentially a web application that breaks without JavaScript and for which there is no alternative means of implementing the functionality that achieves the same purpose.</RAF>

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

<RAF>I believe he was not talking about text in that context.  He was talking about the orginal content, not the text alternative.

Flash content is accessible only in IE on a PC.  Is this "widely supported" enough to say that content is accessible, or must it be accessible on other platforms?  If so, how many and which ones?  Should there be a priority level gradation in this regard?  For instance, content that is accessible to users with a multitude of disabilities using assistive technologies on at least one platform might be deemed to meet Level A conformance requirements.  Content that is accessible on Mac, PC, and Linux might be deemed to conform to Level AA.  Something like that.</RAF>


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]

[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.
[/quote]

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.

<RAF>Unfortunately, it does not in all instances, e.g. SCORM.</RAF>


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]

[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.
[/quote]

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?

<RAF>These are good questions.</RAF>


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]

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

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.

<RAF>How about if a non-text technology is accessible, and cannot be adequately represented with a text alternative, we not require text alternatives.  "If it is accessible" in this regard means "if users with a multitude of disabilities using assistive technologies can interpret the content"</RAF>

Rob

P.S.  Gregg: Sorry for the double posting.  I'll get it right one of these days.
Received on Monday, 26 July 2004 11:16:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:58 UTC