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

Re: definition of checking

From: Charles McCathieNevile <charles@w3.org>
Date: Tue, 7 Dec 1999 11:05:49 -0500 (EST)
To: Ian Jacobs <ij@w3.org>
cc: WAI AU Guidelines <w3c-wai-au@w3.org>
Message-ID: <Pine.LNX.4.20.9912071058320.31909-100000@tux.w3.org>
I would combine the first two points of Ian's rewrite:

Where possible the tool should check automatically (or partially
automatically). Note that syntactic correctness is in any case required by
2.2 and 2.3, but that there are other tests which can be completely or
partialy automated 

Charles McCN

On Tue, 7 Dec 1999, Ian Jacobs wrote:

  Charles McCathieNevile wrote:
  > 
  > On the call we discussed the idea that checking could be split three ways -
  > things that require the author to check, syntax that is machine checkable,
  > and semantics that are machine checkable.
  > 
  > I took an action to write up somthing that could be used as a definition of
  > check for in checkpoint 4.1
  > 
  > Proposal
  > 
  > Check for
  > 
  >    Check for means that the tool must provide some mechanism for testing,
  >    although it may be done by asking the author to check something that the
  >    tool cannot mechanically determine, by checking syntax, which is readily
  >    automated (and required also by 2.2 and 2.3) by mechanically checking semantic
  >    information, such as searching a dictionary for acronyms, or checking
  >    colour combinations, or by asking the author to confirm guesses made by
  >    the tool (for example presenting a linearised version of a page for the
  >    author to check if it makes sense).
  
  Proposed rewrite:
  
      To "check for" an accessibility problem means that it is
      identified by the tool in at least one of the following ways:
  
       a) Where it is possible to identify a problem from syntax, the
          tool must automate this check. For example, check for the
          presence of the "alt" attribute on the HTML IMG element.
  
       b) Where it is possible to identify a problem mechanically but
          not directly from syntax, the tool should automate this
          check. For example, calculate whether two colors do not
          provide sufficient contrast when compared to user preferences.
          When the tool's calculations are best guesses (e.g., 
          linearization of a page), prompt the user to confirm the
          results.
  
       c) Otherwise, prompt the user to verify accessibility. For
  instance,
          if an image has an associated long description, ask the user
          to confirm that the description is appropriate for the 
          image. Subtle, rather than extensive, prompting is more likely
          to be effective in encouraging the user to verify accessibility.
  
   - Ian
  
  
  -- 
  Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
  Tel/Fax:                     +1 212 684-1814
  Cell:                        +1 917 450-8783
  

--Charles McCathieNevile    mailto:charles@w3.org  phone: +61 409 134 136
W3C Web Accessibility Initiative                    http://www.w3.org/WAI
21 Mitchell Street, Footscray, VIC 3011,  Australia (I've moved!)
Received on Tuesday, 7 December 1999 11:05:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:43 UTC