W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

Minority Opinion: Priority of UAAG 12.1 (resent at chair's request)

From: gregory j. rosmaita <oedipus@hicom.net>
Date: Thu, 29 Mar 2001 15:16:05 -0500
Message-ID: <000701c0b88d$15e850e0$99b6f5d0@igor>
To: <w3c-wai-ua@w3.org>
the following emessage, archived at (long URI warning):
from which a thread unspools, refers to the checkpoint currently--or, at
least, in the 23 March 2001 draft of UAAG--numbered 12.1:

12.1 Ensure that at least one version of the product documentation conforms
to at least Level Double-A of the Web Content Accessibility Guidelines 1.0
[WCAG10]. [Priority 1] User agent only.

Note: this post has been resent to the UA list at the chair's request...

Date: Thu, 19 Oct 2000 02:04:03 -0400
To: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
From: "Gregory J. Rosmaita" <unagi69@concentric.net>
Subject: Minority Opinion: UAAG 11.1 (Double-A Documentation)

OBJECTION: WCAG Conformance Level Cited in UAAG Checkpoint 11.1 Too Low

The current checkpoint 11.1 (29 September 2000 Draft) reads,

Ensure that at least one version of the product documentation conforms to
at least Level Double-A of the Web Content Accessibility Guidelines 1.0
[WCAG10]. [Priority 1]

Although I am encouraged that the WCAG conformance level defined as the
minimum for satisfying this checkpoint has been raised from Level-A to
Double-A, I still believe that Double-A conformance is, in this instance,
manifestly insufficient, as documentation is the cornerstone of
accessibility.  It should be incumbent upon UA developers to ensure that at
least one version of the product documentation conforms to Level Triple-A
of the Web Content Accessibility Guidelines, as many of the most commonly
used conventions utilized in software documentation (such as abbreviations
and acronyms) are only accorded a Priority 3 in WCAG, but whose utility in
deciphering documentation is indispensable.


There are several reasons for holding documentation to the highest
standards possible.  Two of the most important are:

1. When one runs assistive technology in conjunction with "mainstream"
applications, one must constantly guard against potential conflicts between
the two, not only in terms of shared hardware, but shared resources (such
as dynamic link libraries). If the "mainstream" application changes a
hardware setting or overwrites a shared resource, one's adaptive equipment
may suddenly stop functioning, causing system crashes, loss of data,
corruption of key files, damage to essential hardware, etc.

2. For many demographic groups, the concept of "learning by perceiving" is
utterly meaningless, because they are physically or cognitively incapable
of obtaining the gestalt view of the application, the intuitiveness of
which is the key to the success of the graphical user interface (as well as
its greatest inherit deficits).

Therefore, while documentation and README files may not be widely used by
the general populace (at least according to the prevailing wisdom, which is
itself derived from the rhetorical question, "Who here reads documentation
before running or loading a new application?"), both are considered
essential components of any application by the quote disabled unquote user.

Unless a disabled user can be assured that he or she has access to a
Triple-A compliant version of the complete documentation provided for the
application, the product cannot be deemed "accessible".

Likewise, if a company fails to ensure that any online documentation,
automatic update features, and download-and-install routines (1) follow the
accessibility guidelines cited in the UAAG Techniques document, and (2)
comply to the Web Content Accessibility Guidelines at a Triple-A level,
that company's should not be allowed to claim conformance to the User Agent
Accessibility Guidelines.

Furthermore, if a company makes a composite conformance claim, it has an
obligation not only to ensure that the third-party applications--which, in
conjunction with the user agent, comprise the subject of the conformance
claim--comply with the UAAG themselves, but that any third party's web site
(especially if it is necessary to download the third party helper
application directly from its developer's web site); as well as any update
routines; the installation procedure; first-run registration dialog boxes;
and the accompanying and online documentation all be as thoroughly
accessible as possible. (This extends to third-party installation
applications/routines utilized by any "mainstream" user agent, as well,
even if it is not cited as part of a composite conformance claim.) A
composite claim can only be considered valid if all of the components of
the composite conformance claim rise to the same level of
accessibility--namely, that outlined both in the UAAG and the UAAG
Techniques document, as well as the platform- and technology-specific
guidelines cited in the UAAG Techniques document, hence my minority opinion.

Gregory J. Rosmaita
The optimist thinks that this is the best of all
possible worlds; the pessimist knows it is.
Gregory J. Rosmaita     <unagi69@concentric.net>
       Webmaster & Minister of Propaganda
The Visually Impaired Computer Users' Group of
the New York City Metropolitan Area (VICUG NYC)
Received on Thursday, 29 March 2001 15:14:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:30 UTC