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:
StickyKeys: Enables the user to keep the Control, Shift, Alt, or other modifier keys temporarily latched or locked while other keys are pressed, enabling them to type capital letters, Control-C, Alt-M, Alt-Control-Backspace, and so forth. People who can't press more than one key at a time are users.
MouseKeys: Enables a group of keys to emulate a mouse. Pressing keys in this group will move a pointer around the screen and perform mouse button actions (for instance, double-clicking). People who can't move a mouse or press its buttons are users.
RepeatKeys: Enables the user who has trouble releasing keys quickly once they press to slow down how fast keys start repeating once they're pressed. People who have trouble releasing a key before it starts to repeat are users.
SlowKeys: Enables users who regularly hit multiple keys by accident while typing to introduce a key press acceptance delay that gives them time to release the keys they accidentally press before the system actually passes the key press event along to the requesting process. People who have trouble hitting a single key are users.
BounceKeys: Requires a delay between keystrokes before accepting the next keypress so users with tremors can prevent the system from accepting inadvertent keypresses after the system accepted is pressed. People who have tremors that cause them to hit keys multiple times are users.
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:
"Configuration and Setting Requirements" enumerates the features along with the associated controls, configurability, and minimum ranges for each that must be exposed to the user in a user interface.
"End-User Notification, Keyboard Invocation, and Mouse Emulation Requirements" enumerates the additional notification and controllability some features must provide the user that are separate from those provided the user in user interface provided for the above controls.
"Feature Behavior Requirements" identifies the type of behavior that should result when the user interacts with each feature.
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.
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.
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.
|Feature||Functionality||Type of Control||Option's Variable Ranges|
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
|General Requirement||Feature||Functionality Required|
|Provide a visual indication showing the state of keys and buttons.||StickyKeys||
a keyboard on/off gesture.
an audible signal that indicates the changed state of a modifier key.
||Provide an audible signal for
each of the following conditions:
|Provide the ability
to manipulate the mouse from the keyboard.
the ability to do the following on systems providing a mouse:
The following subsections provide more detailed descriptions and requirements of the various keyboard access features from a user interaction standpoint.
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:
A user may latch more than one modifier at a time by pressing any number of unique modifier keys before pressing a non-modifier key.
A user may lock a modifier by pressing/releasing the modifier key twice in a row.
A user may lock more than one modifier at a time.
Any latched or locked modifiers will also be used in conjunction with mouse events.
Pressing mouse buttons will result in the same behavior as pressing a non-modifier key.
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
When MouseKeys is enabled, the system must behave as follows:
When the user presses and holds a key for moving the mouse cursor, the cursor will move slowly at first and then accelerate based upon the configuration settings listed in Table 1. When the user releases the key, the cursor will stop immediately.
When the user presses a key for selecting the "active" mouse button, no input events will be generated. Instead, the key will set the button to be used for the button actions described below.
When the user presses the key for performing a single-click action, the system will generate a button click (i.e., a sequential button press and release events) using the current "active" button (see above).
When the user presses the key for performing a double-click action, the system will generate a button double-click (i.e. sequential button press, release, press, release events) using the current "active" button (see above).
When the user presses the key for holding down a button, the system will generate a button press event using the current "active" button (see above). The button will remain logically pressed even when the user releases the key. Following this action, the user may use other keys to move the mouse cursor so as to perform a drag operation.
When the user presses the key for releasing a button, the system will generate a button release event using the current "active" button (see above).
More than one mouse button can be logically pressed at a time.
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 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 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
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.