Keyboard Access Functional Specification v0.8


Date: 01/19/05

Authors:
Earl Johnson; Editor
Bill Haneman
Mark Novak
Willie Walker


What This Specification Defines

This functional specification defines the minimum level of keyboard accessibility support and notification that must be provided to the user by an FSG Certified X Windowing System. This support guarantees that users with a variety of physical disabilities will always have a basic level of access to the windowing system's core functions - keyboard input and mousing. The features defined in this specification provide the user with the following type of support:

Overview

The "Keyboard Access Functional Specification" identifies the features and behaviors a compliant desktop platform must provide in order to ensure a basic level of keyboard based access. The features in this specification are largely dependent on support provided at the X Server level of the platform. This functional specification covers 3 main areas:

Scope

This specification defines the support that must be built into the X Server The capabilities provided by these features emulate mouse based events and/or determine how the X server  interprets and processes a user's keypresses. Defining and/or specifying the exact user interface via which the features are presented to the user is beyond the scope of this specification, with the exception of a few keyboard shortcuts which are explicitly called out in the second table ["End-User Notification and Keyboard Invocation Requirements"]. Specifying the keysequences for how a user controls and interacts the desktop and its contents, e.g. Control-C is Copy, is also outside the scope of this specification.

Intended Audience

This specification is aimed at the conformance tester and the developer working to ensure their Linux offering provides the functionality called for in this specification. This specification does not provide instructions on how to use the functionality defined herein, or give style recommendations, or, for the most part, define a user interface.

Functional Specification

Configuration and Setting Requirements

This section identifies the configurable functionality that must be available to the user through a user interface, and the range and degree to which they must be configurable by the end user.  The ranges associated with some of these controls identify the minimum range that must be supported; it is acceptable for an offering's maximum and minimum values to be outside these ranges as long as the ranges defined below are supported.

Table 1: Configuration and Setting Requirements
Feature Functionality Type of Control Option's Variable Ranges
StickyKeys
  1. Turn StickyKeys on/off.
  2. Press modifier key twice to lock.
  3. Turn StickyKeys off when two keys are pressed simultaneously.
  4. Enable keyboard on/off shortcut.
  5. Provide an audible signal when a modifier is pressed.
  1. Boolean
  2. Boolean
  3. Boolean
  4. Boolean
  5. Boolean
  1. N/A
  2. N/A
  3. N/A
  4. N/A
  5. N/A
MouseKeys
  1. Turn MouseKeys on/off.
  2. Mouse cursor step size [aka “initial jump”] – the initial step size. the pointer makes when a direction key is pressed.
  3. Delay before the acceleration that follows the initial step starts.
  4. Initial pointer velocity.
  5. Delay till the cursor reaches maximum speed.
  6. Maximum cursor speed.
  1. Boolean
  2. Variable
  3. Variable
  4. Variable
  5. Variable
  6. Variable
  1. N/A
  2. Initial jump: 1-10 pixels.
  3. Acceleration start delay: 0 – 1000 ms.
  4. Initial velocity: 1 – 200 pixels/sec.
  5. Time to reach full acceleration: 100 - 10000 ms.
  6. Maximum speed: 1 - 2,000 pixels/ sec.
RepeatKeys
  1. Turn RepeatKeys on/off.
  2. Repeat delay.
  3. Repeat rate.
  1. Boolean
  2. Variable
  3. Variable
  1. N/A
  2. Range: 0.10 to 5.0 seconds.
  3. Range: 0.02 characters/second [i.e. 1 character takes 50 seconds] to 10 characters/second.
SlowKeys
  1. Turn SlowKeys on/off.
  2. Provide an audible signal when SlowKeys is about to be turned on/off via the keyboard.
  3. Provide an audible signal when a key is pressed
  4. Provide an audible signal when a key is accepted.
  5. Provide an audible signal when a key is rejected.
  6. Enable keyboard on/off shortcut.
  7. Acceptance delay.
  1. Boolean
  2. Boolean
  3. Boolean
  4. Boolean
  5. Boolean
  6. Boolean
  7. Variable
  1. N/A
  2. N/A
  3. N/A
  4. N/A
  5. N/A
  6. N/A
  7. Range: 0.050 to 10 seconds .001 seconds is time expected where an accidental keypress will not register and won't be a redundant/conflicting with repeating.

BounceKeys
  1. Turn BounceKeys on/off.
  2. Provide an audible signal when a key is rejected.
  3. Debounce time.
  1. Boolean
  2. Boolean
  3. Variable
  1. N/A
  2. N/A
  3. Range: 0.1 to 5 seconds.
Supporting features
  1. Provide a means of requesting a warning dialog any time a Keyboard Access feature is invoked from the keyboard.
  2. Provide a "never time-out" option.
  3. Provide an option for requesting an audible signal when a Keyboard Access  feature is turned on/off.
  4. Provide a visual indication showing when the system generates a audible signal.
  5. Make the system-generated bell silent.
  6. Provide a means of testing changes to any Keyboard Access test settings.
  7. Provide a time-out option that turns StickyKeys and SlowKeys off automatically after a specified period of time while still allowing features to be invoked on from the keyboard.
  1. Boolean
  2. Boolean
  3. Boolean
  4. Boolean
  5. Boolean
  6. Text field
  7. Variable
  1. N/A
  2. N/A
  3. N/A
  4. N/A
  5. N/A
  6. N/A
  7. 1-30 minutes

End-User Notification, Keyboard Invocation, and Mouse Emulation Requirements

This section enumerates the notifications that must be provided the user when specified changes to keyboard state occur [exclusive of audio notifications already implicit in Table 1], and identifies the features that must be invocable via a keyboard gesture. This functionality is separate from that presented in the user interface exposing the controls identified in Table 1.

Table 2: End-User Notification, Keyboard Invocation, and Mouse Emulation Requirements
General Requirement Feature Functionality Required
Provide a visual indication showing the state of keys and buttons. StickyKeys
  1. Indicate when StickyKeys is on.
  2. Indicate when a modifier[s] is in a latched state.
  3. Indicate when a modifier key[s] is in a locked state.
MouseKeys
  1. Indicate when MouseKeys is on.
  2. Indicate which mouse button is active.
  3. Indicates when the active mouse button is up or down.
SlowKeys
  1. Indicate when SlowKeys is on.
  2. Indicate when a key is pressed.
  3. Indicate when a key press is accepted.
  4. Indicate when a key press is rejected.
Provide a keyboard on/off gesture.
StickyKeys
  1. Provide the ability to toggle StickyKeys on and off from the keyboard.
    On systems that utilize a keyboard: press Shift key 5 consecutive times.

MouseKeys
  1. Provide the ability to toggle MouseKeys on and off from the keyboard on systems that utilize a pointing device.

SlowKeys
  1. Provide the ability to toggle SlowKeys on and off from the keyboard.
    On systems that utilize a keyboard: hold down Shift for 8 seconds.
Provide an audible signal that indicates the changed state of a modifier key.
StickyKeys
Provide an audible signal for each of the following conditions:
  1. A modifier is latched.
  2. A modifier is locked.
  3. A modifier is unlatched or unlocked.
Provide the ability to manipulate the mouse from the keyboard.
MouseKeys Provide the ability to do the following on systems providing a mouse:
  1. Move the pointer via a key press.
  2. Activate the active mouse button via a keypress [e.g. single and double click].
  3. Change the active mouse button via a keypress.
  4. Hold down a mouse button via a keypress.
  5. Allow multiple mouse buttons to be pressed.

Feature Behavior Requirements

The following subsections provide more detailed descriptions and requirements of the various keyboard access features from a user interaction standpoint.

StickyKeys

Some users are unable to physically press more than one key at a time.  With StickyKeys, the user can first press a modifier key, release it, and then press another key.  For example, to get an exclamation point on a US QWERTY keyboard, the user can press the Shift key, release it, and then press the 1 key.

StickyKeys is required for systems that have a keyboard that requires the user to press more than one key at a time.  When StickyKeys is enabled, the keyboard must behave as follows:

MouseKeys

Some users are able to use a keyboard but are unable to use devices such as a mouse or trackball.  MouseKeys permits the user to emulate a mouse from the keyboard, and is required for systems that have an external pointing device such as a mouse or trackball.

When MouseKeys is enabled, the system must behave as follows:

RepeatKeys

RepeatKeys is of primary use to users who have difficulty removing their fingers from keys before the auto-repeat behavior is activated.  RepeatKeys is required for systems that provide an auto-repeat behavior.  When RepeatKeys is enabled, the auto-repeat behavior is identical to the normal auto-repeat behavior of the system, but the system will use the repeat delay and repeat rate timings described in Table 1.

SlowKeys

SlowKeys enables users who regularly hit multiple keys by accident while typing.  SlowKeys does so by
requiring the user to press and hold a key for a period of time (the SlowKeys "acceptance delay" described in Table 1) before the key is accepted, and is required on systems that provide a keyboard.

When SlowKeys is activated, the user must press and hold a key for the "acceptance delay" period of time before it is accepted.  Once the key is accepted, if the user continues to hold the key, the RepeatKeys settings will be used to handle the auto-repeat behavior.  If the user releases a key before the "acceptance delay," the system will treat the press/release as though they never happened.

BounceKeys

BounceKeys requires a delay (the "debounce time") between keystrokes before accepting the next keypress, and is typically used by users with tremors to prevent inadvertent keypresses.  BounceKeys is required on systems that provide a keyboard.

When BounceKeys is enabled, the first press of a key will be immediately accepted by the system.  When the user releases the key, they must wait for the "debounce time"to be met before pressing that same key again.  If the user presses the key before the "debounce time" has expired, that key press/release will be ignored.  Note that the "debounce time" only applies to the last key released - that is, if a user presses a *different* key immediately after releasing a key, that different key will be accepted.