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

Scope of configurable settings

From: <pjenkins@us.ibm.com>
Date: Wed, 18 Aug 1999 18:24:47 -0500
To: w3c-wai-au@w3.org
Message-ID: <852567D1.00809533.00@d54mta08.raleigh.ibm.com>

An authoring tool developer commented that parts of Guideline 6
"Provide methods of checking and correcting inaccessible content"
drift too far into prescribing exactly how designers are to design their tools.

He agrees with 6.1, 6.2, and 6.4 :
6.1 Check for and alert the author to accessibility problems. (Priority 1...
6.2 Assist authors in correcting accessibility problems. (Priority 1 for ...
6.4 Allow the author to override any removal of unrecognized markup. [Priority

But feels that 6.3, 6.5, and 6.6 are too prescriptive AND not required for
generating accessible content:

6.3 Allow users to control *both* the *nature* and *timing* of accessibility
alerts. [Priority 2]
6.5 Provide the author with a *summary* of the document accessibility status *on
a configurable schedule*. [Priority 3]
6.6 Allow the author to perform element transformations. [Priority 3]

These three are really techniques and possible design features for meeting the
first 3 checkpoints.  The "how and when" of checking or alerting or assisting
are part of the design of the tool and not always under control of the user.
Requiring a feature [Priority 2] to allow the user to have control of both the
nature *and* timing is a tall complex development order, is unclear which alerts
[all?] are applicable, and is unspecified about definition of *timing/schedule*
and *summary*.   For example, is providing only one choice on timing adequate?
Either at time of image insertion and/or when executing the access checker
function?  Is a Green, Yello, Red indicator summary adequate, or does it need to
be a log file for each element of the page?

The proposal is to move these 3 into the techniques documents *or* make them all
[change 6.3] priority 3 AND simplify/clarify the checkpoint wording.  For
6.3a  Allow users *some* control over the accessibility alerts. [Priority 3]
6.3b  Allow users *some* control over the format/nature of the accessibility
alerts. [Priority 3]
6.5  Provide a summary of the accessibility status. [Priority 3]
   in the techniques include a list of suggestions, including # of images
without ALT=text, etc.
   delete the part about the configurable schedule

Quoting from the techniques document: "The art of attracting users' attention is
a tricky issue. The way users are alerted, prompted, or warned will influence
their view of the tool and their opinion of accessible authoring. "  is the
concern express here with 6.3, 6.5, 6.6.   I believe we can be more exact in the
checkpoint wording in a future release of the guidelines once we get more
techniques implement by authoring tool developers AND we get more data on which
techniques are more effective.  I believe we are now relying more on our "wants"
and "ideas" of what will be effective and we need to work more with developers
on implementing the basics.

Phill Jenkins
Received on Wednesday, 18 August 1999 19:24:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:28:21 UTC