"Gregory J. Rosmaita" wrote:
>
> 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...
Gregory,
The Working Group resolved at the 17 August teleconference
(refer to summary from Chair [1]) to accept the proposal to
allow claims of conformance for software used in tandem provided
that all components be identified.
Also, per the same resolution to issue 294, the following
text about the importance of accessibility by default
appears in the 29 September Guidelines [3], section 3.2:
<BLOCKQUOTE>
User agent developers are strongly encouraged to design software that
conforms in the default configuration. Users may not be able to
install complementary software because the default configuration does
not allow it easily (e.g., the mechanisms for retrieving and
installing plug-ins are not accessible by default), because they don't
have access privileges on a public computer, etc. In order for people
to use the software at all, the installation procedure (and any
subsequent software update procedures) must be accessible according to
the guidelines of this document. For example, the software must
provide device-independent access and accessible documentation of the
installation.
</BLOCKQUOTE>
For previous discussions on accessible installation, refer to:
1) Minutes of 10 December 1999 IBM face to face meeting [4]
2) Deletion of explicit mention of "installation, documentation,
UI configuration" from checkpoint 1.1 per resolution of
31 August teleconference [5] (there were no subsequent
objections on the list).
The following text appears in section 1.2 of the 29 September
draft:
<BLOCKQUOTE>
The user agent installation procedure needs to be accessible
otherwise the user will not be able to use it at all.
Most of the requirements in this document should be adopted for the
installation procedure to ensure its accessibility.
</BLOCKQUOTE>
Recall also that installation according to system conventions
is covered by checkpoint 5.8.
- Ian
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0267.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0244.html
[3] http://www.w3.org/WAI/UA/WD-UAAG10-20000929/
[4] http://www.w3.org/WAI/UA/1999/12/ftf-19991210#issue-147
[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0341.html
> 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>
> --------------------------------------------------------
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 831 457-2842
Cell: +1 917 450-8783