Re: Some discussion points for issue 294

note: i have been attempting to post this to the UA list since i was able 
to retrieve it on 10 august, but haven't been able to do so due to 
continuing connectivity problems...  don't know if the WG has resolved this 
issue or not, as this was the last message i received from the UA list 
until september 27, and my current connection's too precarious to fire up a 
UA to check the issues list (i've already lost connection thrice just 
typing this intro), but here are my 2 cents worth/gut reaction to ian's 
list of talking points raised by his review of the 28 July 2000 draft of 
UAAG with Tantek Çelik...

aloha, ian!

on 9 august 2000, you asked,

quote
What's the difference between installing from the Web and installing from a CD?
unquote

none--both need to follow the applicable accessibility guidelines (WCAG for 
web-based download (as well as download-and-install) interfaces, and the 
pertinent platform or language guidelines for software developers cited in 
the UAAG (and ATAG) Techniques document....

ian also observed:

quote
3) Jon Gunderson and others have pointed out that users cannot always 
install new software or features or modules (e.g., when they work in a 
public environment such as a library). This argument is not limited to 
accessibility issues: a user agent may be unusable for any number of 
reasons related to lack of resources. It's the responsibility of the 
systems team in this particular case to ensure that the software is usable. 
Does this mean that it's inacceptable to say "get these modules from the 
Web" just because some users don't have access privileges to install those 
modules? I don't think that that's an accessibility issue.
unquote

on the contrary, it is an accessibility issue -- what's the difference 
between an inaccessible public terminal (which is inaccessible because a 
user of that public terminal doesn't have the requisite permissions to 
download-and-install modules that would make the UA more accessible) and a 
public library, whose contents are inaccessible to a patron because the 
library doesn't have an access ramp, doors wide enough to accommodate 
wheelchairs and scooters?

accessibility is a sub-set of usability, or vice versa depending upon your 
point of view....  the important fact is that, yes, if a UA is dependent 
upon certain modules in order to satisfy a conformance claim, then it is 
incumbent upon the UA manufacturer to:

(a) ensure that the download-and-install routines are accessible (i.e. 
conform to WCAG, conform to some published  software accessibility 
standards (such as those promulgated by TRACE or IBM), and, if the UA is 
platform-specific, to any applicable platform specific accessibility 
standards/protocols;

(b) ensure that if the download and install routine involves a reboot of 
the system or any type of registration (such as the sending of one's name, 
address, email address, etc.) mechanism, that all subsequent dialogs (i.e. 
those generated by the downloaded component _after_ it has been downloaded 
and/or installed) rise to the same standards outlined in point (a) above;

anything else is insufficient

ian also asked, quote
4) If the UA includes a documented feature that allows users to get and 
install modules that provide accessibility features at the "click of a 
button", would that count as native support?  What if this is used as a way 
to get accessibility features into deployed browsers (rather than having to 
wait for a new release)?
unquote

if the quote click of a button unquote mechanism isn't accessible (i.e. 
device and modality independent), then this is the mootest of 
points...   if the update mechanism is accessible, then the UA could claim 
conformance for version XYZ, as opposed to version X, which is the quote 
general distribution unquote version of the software...   so, for example, 
if i am using Pineal Web Version 3.0 (which anyone can download or purchase 
and install), but in order to make it accessible i have to download a 
modules and patches, then i would expect that the version number would 
change -- say to Pineal Web Version 3.0.2.5 -- and the conformance claim 
would then only cover the UA _as updated/patched_

note that, i am a strong proponent of the strategy of deploying modules 
that provide accessibility as a means of deploying accessibility features 
into older/legacy/extant browsers, but only:

(a) on the understanding that the accessibility features will be rolled 
into the next full release of the UA (this is a commitment to which i would 
argue we must hold claimants); and

(b) if verbiage is inserted into UAAG that explicitly states that if 
modules or patches that promote accessibility are made available, then only 
the patched version of the UA (with its corresponding version number) 
conforms to UAAG

ian's final point was, quote:
5) If downloading modules is considered acceptable in some circumstances, 
the UA must already be accessible enough to allow users to  download those 
modules.
unquote

agreed, but i would take this one step further and insist that the 
download, installation, and registration (if necessary/required) routines 
must also be accessible and adhere to standards that have been generated to 
ensure the accessibility of software in general...

gregory.

--------------------------------------------------------
He that lives on Hope, dies farting
      -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
    WebMaster and Minister of Propaganda, VICUG NYC
         <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------

Received on Thursday, 19 October 2000 02:22:30 UTC