Re: Scope of configurable settings

I agree that 6.5 and 6.6 are not required, or even especially important,
although they are beneficial, hence the P3.

I think that part of the configurability for 6.3 is in fact an issue of user
interface accessibility. It is important, if not essential, that the alerting
be configurable by the user as part of the general requirement for
configurability of the user interface.

I would support a change to making the nature and timing of alerts a P3
requirement (or two) or of moving them to techniques. I would like to note
the relationshipto user interface accessibility with a cross reference, and
since I think it is more important from an interface perspective than an
authroing perspective I am inclined towards making it a technique, which will
mean the cross reference is less confussing in terms of suggesting a possible
conflict in priority level.

Thanks for the suggestions about how to make the techniques more helpful -
I'll put them into the next draft unless someone thinks it isn't a good idea.

cheers

Charles McCN

On Wed, 18 Aug 1999 pjenkins@us.ibm.com wrote:

  
  
  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
  2]
  
  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
  example:
  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.
  
  Regards,
  Phill Jenkins
  
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Thursday, 19 August 1999 01:05:51 UTC