Checkpoint 2.1 (revisions from Feb 13 Telecon)

At the February 13 Telecon, we discussed a number of modifications to
Checkpoint 2.1. A copy of the checkpoint with the revisions we discussed
is included below for inclusion in the next draft.
 
List of changes:
 
1. revised checkpoint text
2. replaced definition of character input with definition of keyboard 
   interface
3. added an example to expand on types of keyboard operable content   

Issue: What if something is designed so that it ONLY works on a device
for which there is no AT. Can the content be "accessible" if it meets
the guidelines but only runs on a device for which there is no AT – and
therefore cannot be accessed?  Do we cover this somewhere?   

---------------------------
 
Checkpoint 2.1 Ensure that all of the functionality is operable at a 
minimum through a keyboard or keyboard interface. 
 
Success criteria
You will have successfully met Checkpoint 2.1 at the Minimum Level if:
    1. all of the functionality of the content is operable at a minimum 
       through a keyboard or keyboard interface. 
          + Note: refer to checkpoint 5.3 for information regarding user
            agent support.
 
You will have successfully met Checkpoint 2.1 at Level 2 if:
    * (presently no additional criteria for this level.)
 
You will have successfully met Checkpoint 2.1 at Level 3 if:
     * (presently no additional criteria for this level.)
 
The following are additional ideas for enhancing a site along this
particular dimension:
     * (presently no additional criteria for this level.)
 
Definitions (informative)
   A keyboard interface is the point where the application accepts any
   input that would come from the keyboard (or optional keyboard).
 
Benefits (informative)
     * Individuals who are blind (and cannot use pointing devices) can
       have access to the functionality of the Web content or site.
     * Individuals with severe physical disabilities can use speech
       input
       (which simulates keystrokes) to both enter data and operate the
       interface elements on the page.
     * Individuals who are physically disabled and cannot use pointing 
       devices or speech input can have access to the functionality of 
       the Web content.
 
Examples (informative)
     * Example 1: operation with multiple input devices.
       The content relies only on focus-in, focus-out, and activation
       events; these are defined in the API of the environment for which
       the content is written, and are intended to be operable by a
       variety of input devices, including pointing devices, keyboards
       and speech input systems.
     * Example 2: examples of Web content that would and would not be 
       operable from a keyboard or keyboard interface
           - If it's written to be operable from a computer keyboard, 
             it conforms. (because it is operable from the keyboard.) 
           - If it's written to be used on a device that doesn’t usually

             have a keyboard such as a cell phone and but it can be 
             controlled by an optional keyboard for that device,
             it conforms. (A person who needs a keyboard - or alternate 
             keyboard - can use it to control the application.)
           - If it's written to be used with a device that doesn’t have
a
             keyboard, but it could also be used by similar devices that
do
             and it would work with their keyboard, it conforms. (A
person
             who needs a keyboard would not buy the device without the 
             keyboard. That device may itself not be considered
accessible. 
             But the content can be controlled from a device with a 
             keyboard and therefore conforms to this checkpoint.)
           - If it's written to work with devices that do not have 
             keyboards and it can not be used by any other devices 
             that do have keyboards, then it does not 
             conform. (It cannot be accessed via keyboard.)


--
Ben Caldwell | caldwell@trace.wisc.edu
Trace Research and Development Center (http://trace.wisc.edu)  

Received on Wednesday, 26 February 2003 14:54:55 UTC