http://accessibility.linux-foundation.org/a11yspecs/kbd/kafs-rc3.html
This specification is copyright 2005, 2008 Open Accessibility (A11y) at The Linux Foundation. All Rights Reserved.
This section is informative
Persons unable to use a keyboard and mouse sometimes use alternative input devices. However, many users can be accommodated programatically through software that causes a standard keyboard to behave differently. Many of these features and behaviors have long been available in The X Keyboard Extension: Library Specification Library (X Version 11, Release 6.4) [XKB] specification.
Individuals with mobility impairments will benefit by having such features built-in and available through standard activation strategies, such as tapping the Shift key five times to activate StickyKeys. The routines provided by the API will also benefit assistive technologies such as on screen keyboard and screen reader applications.
This specification, developed by the Open A11y Workgroup's Keyboard Special Interest Group, identifies and adopts a subset of the XKB Keyboard Extension specification in order to provide standard keyboard features and behaviors required by persons with mobility impairments. A companion document, "Generic Test Assertions for Manual Testing (KAFS GTA)", which identifies how to test for compliance with this specification, is also available.
To provide feedback, report errors or to inquire about this document,
please send email to
accessibility-rfc@a11y.org
, a publicly archived emailing list.
This section is informative
The normative version of Keyboard Access Functional Specification, RC3 (KAFS) is the XHTML Strict 1.0 version, located at:
http://accessibility.linux-foundation.org/a11yspecs/kbd/kafs-rc3.html
All other versions (and any future translations) of Keyboard Access Functional Specification, RC3 (KAFS RC3) are non-normative.
This section is normative
This functional specification defines the minimum level of keyboard accessibility support and notification that must be provided to the user by a Linux Foundation-certified X Windowing System. This support ensures 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 controlling the system pointer (where available).
The features in this specification are largely dependent on support provided at the operating system level of the platform. This functional specification covers the 3 areas described below:
This section is normative
The features and range of support prescribed in this document should not be taken as state-of-the-art, nor do they constitute the current best available practice.
Compliance with this specification is necessary, but not sufficient, for supporting adequate end-user keyboard access to the desktop environment. Meaningful end-user access to the desktop environment, and the applications hosted thereon requires that those applications are designed with keyboard access in mind; conformance of an operating environment to this specification does not imply that such applications are themselves accessible.
This section is normative
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.
This section is informative
http://accessibility.linux-foundation.org/a11yspecs/kbd/updates/kafs-rc3-errata.html
accessibility-rfc@a11y.org
.
Please report any technical problems encountered with this document or the
resources to which it links, please contact webmaster@a11y.org
.This section is normative
The features defined in this specification provide the user with the following type of support:
This section is normative
This functional specification defines the support that must be built into the system. The capabilities provided by the features in it define the pointer based events and capabilities that must be emulated by the system as well as how the system should interpret and process a user's keypresses. For the most part, defining and/or specifying the exact user interface[s] these features are presented in is beyond the scope of this specification. The one exception area is keyboard shortcuts that are already considered de facto standards. These shortcuts are explicitly defined 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.
An exact set of test assertions for the user interface cannot be provided in this document because it does not prescribe what the user interface must look like. It is left to others, most likely the platform provider, to develop their own set of assertions for testing their specific implementation against this functional specification. The companion "Generic Test Assertions for Manual Testing", which identifies how to test for compliance with this specification, was developed to address this limitation. A third document that will be produced, the "XKB's Keyboard Access Support Specification", provides the first free software based implementation of this specification off which many platforms have based their keyboard access implementation.
This section is normative
This section is normative
This section identifies the configurable functionality each feature must make available to the user, the controls associated with the defined functionality, and the required ranges that must be supported in variable controls. It is important to note that the ranges associated with a variable type control are the minimum that must be supported; it is acceptable to provide a superset of these ranges, i.e. to support a wider range of settings than the minimum specified below. It is also acceptable to provide finer granularity, linear or non-linear, than that specified herein as long as the values defined below are supported. Unless otherwise noted, sub-features of features with a primary boolean control are only required to be available to the user when the primary boolean control has a value of "true". For instance, feature 1.3 need not be available to the end user unless 1.1 (the StickyKeys boolean) is "true". However, exposing these options in the user interface while the control is "false" should not in itself be deemed a conformance failure.
Feature | Functionality | Type of Control | Option's Variable Ranges |
---|---|---|---|
|
|||
1. StickyKeys | 1.1. Turn StickyKeys on/off. [test for Feature 1.1] | Boolean | N/A |
1.2. Press modifier key twice to lock. [test for Feature 1.2] | Boolean | N/A | |
1.3. Turn StickyKeys off when two keys are pressed simultaneously. [test for Feature 1.3] | Boolean | N/A | |
1.4. Provide the ability to request an audible signal when a modifier is latched, locked, or unlocked. [test for Feature 1.4] | Boolean | N/A | |
2. MouseKeys | 2.1. Turn MouseKeys on/off. [test for Feature 2.1] | Boolean | N/A |
2.2. Delay before the acceleration that follows the initial step starts. [test for Feature 2.2] | Variable | Acceleration start delay: 1-1000 ms Required adjustment granularity at low end of range: 10 ms. |
|
2.3. Initial pointer velocity/repeat interval. [test for Feature 2.3] | Variable | Initial velocity: 1-200 pixels/sec Required adjustment granularity at low end of range: 2 pixels/sec. Note: this may be exposed as either a velocity in pixels/sec or a repeat interval between succesive pointer motions. |
|
2.4. Delay till the pointer reaches maximum speed. [test for Feature 2.4] | Variable | Time to reach full acceleration: 100-10000 ms Required adjustment granularity at low end of range: 200 ms. |
|
2.5. Maximum pointer speed, in pixels/sec. [test for Feature 2.5] | Variable | Maximum speed: 1-2000 pixels/sec Required adjustment granularity at low end of range: 10 pixels/sec. |
|
3. RepeatKeys | 3.1. Turn RepeatKeys on/off [test for Feature 3.1] | Boolean | N/A |
3.2. Repeat delay [test for Feature 3.2] | Variable | Range: 0.10 to 5.0 seconds Required adjustment granularity at low end of range: 0.1 seconds. |
|
3.3. Repeat rate [test for Feature 3.3] | Variable | Range: 0.2 characters/second
(i.e. 1 character takes 50 seconds) to 10
characters/second. Required adjustment granularity at low end of range: 0.3 characters/second. |
|
4. SlowKeys | 4.1. Turn SlowKeys on/off. [test for Feature 4.1] | Boolean | N/A |
4.2. Provide the ability to request an audible signal when SlowKeys is about to be turned on/off via the keyboard. [test for Feature 4.2] | Boolean | N/A | |
4.3. Provide the ability to request an audible signal when a key is pressed. [test for Feature 4.3] | Boolean | N/A | |
4.4. Provide the ability to request an audible signal when a key is accepted. [test for Feature 4.4] | Boolean | N/A | |
4.5. Provide the ability to request an audible signal when a key is rejected. [test for Feature 4.5] | Boolean | N/A | |
4.6. Acceptance delay. [test for Feature 4.6] | Variable | Range: 0.05-10 seconds Required adjustment granularity at low end of range: 0.25 seconds. |
|
5. BounceKeys | 5.1. Turn BounceKeys on/off. [test for Feature 5.1] | Boolean | N/A |
5.2. Provide the ability to request an audible signal when a key is rejected. [test for Feature 5.2] | Boolean | N/A | |
5.3. Debounce time. [test for Feature 5.3] | Variable | Range: 0.1-5 seconds Required adjustment granularity at low end of range: 0.1 seconds. |
|
6. ToggleKeys | 6.1. Turn ToggleKeys on/off. [test for Feature 6.1] | Boolean | N/A |
7. Supporting Features | 7.1. Provide a means of requesting a warning dialog any time the SlowKeys or StickyKeys feature is invoked from the keyboard. [test for Feature 7.1] | Boolean | N/A |
7.2. Provide an option for requesting an audible signal when a Keyboard Access feature is turned on/off from the keyboard. [test for Feature 7.2] | Boolean | N/A | |
7.3. Provide a visual indication showing when the system generates an audible ('bell') signal. [test for Feature 7.3] | Boolean | N/A | |
7.4. Provide a means of enabling the keyboard shortcuts for StickyKeys and SlowKeys to be turned on/off; turning this functionality off turns the features off and disables the keyboard shortcuts. [note a] [test for Feature 7.4] | Boolean | N/A | |
7.5. Provide a time-out option that turns StickyKeys and SlowKeys off automatically after a specified period of time without keyboard activity; it still must be possible to turn StickyKeys or SlowKeys on from the keyboard when this feature is turned on. [note a] [test for Feature 7.5] | Variable | Never TimeOut then Range: 1 to 30 minutes. Required adjustment granularity at low end of range: 4 minutes. |
|
7.6. Provide a never time out option for StickyKeys and SlowKeys. [note a] [test for Feature 7.6] | Optional | Never time out. |
This section is normative
This section describes the notifications that must be provided the user when specified changes to keyboard state occur -- these include visual and audio notifications that are not already implicitly defined in Table 1.
General Requirement | Feature | Functionality Required |
---|---|---|
1. Provide a visual indication showing the state of keys and buttons. | 1.1. StickyKeys | 1.1.1. Indicate when StickyKeys is on. [Functionality test 1.1.1] |
1.1.2. Indicate when a modifier(s) is in a latched state. [Functionality test 1.1.2] | ||
1.1.3. Indicate when a modifier(s) is in a locked state. [Functionality test 1.1.3] | ||
1.2. MouseKeys | 1.2.1. Indicate when MouseKeys is on. [Functionality test 1.2.1] | |
1.2.2. Indicate which pointer button is active. [Functionality test 1.2.2] | ||
1.2.3. Indicate when the active pointer button is up or down. [Functionality test 1.2.3] | ||
1.3. SlowKeys | 1.3.1. Indicate when SlowKeys is on. [Functionality test 1.3.1] | |
1.3.2. Indicate when a key is pressed. [Functionality test 1.3.2] | ||
1.3.3. Indicate when a key press is accepted. [Functionality test 1.3.3] | ||
1.3.4. Indicate when a key press is rejected. [Functionality test 1.3.4] | ||
2. Provide a keyboard on/off guesture. | 2.1. StickyKeys | 2.1.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. [Functionality test 2.1.1] |
2.2. MouseKeys | 2.2.1. Provide the ability to toggle MouseKeys on and off from the keyboard on systems that utilize a pointing device. [Functionality test 2.2.1] | |
2.3. SlowKeys | 2.3.1. Provide the ability to toggle SlowKeys on and off from the keyboard. On systems that utilize a keyboard: hold down the Shift key for 8 seconds. [Functionality test 2.3.1] | |
3. Provide an audible signal that indicates when a keyboard access feature or feature functionality has changed state. | 3.1. General | 3.1.1. Each keyboard access feature must provide an audible signal when it is turned on or off. [Functionality test 3.1.1] |
3.1.2. The signal that is generated when a keyboard access feature has been turned on or off must be the same as that used on the other keyboard access features. [Functionality test 3.1.2] | ||
3.1.3. A keyboard access feature's "On" audible signal must be different from its "Off" audible signal. [Functionality test 3.1.3] | ||
3.1.4. Functionality in a keyboard access feature that essentially turns something On or Off should use an audible signal with a timbre similar to the one generated when a keyboard acess feature is turned "On" or "Off". [Functionality test 3.1.4] | ||
3.2. StickyKeys | 3.2.1. Provide an audible signal when a modifier is latched. [Functionality test 3.2.1] | |
3.2.2. Provide an audible signal when a modifier is locked. [Functionality test 3.2.2] | ||
3.2.3 Provide an audible signal when a modifier is unlatched or unlocked. [Functionality test 3.2.3] | ||
3.3. SlowKeys | 3.3.1. Provide an audible signal when SlowKeys is about to be turned on/off via the keyboard. [Functionality test 3.3.1] | |
3.3.2. Provide an audible signal when a key is pressed. [Functionality test 3.3.2] | ||
3.3.3. Provide an audible signal when a key is accepted. [Functionality test 3.3.3] | ||
3.3.4. Provide an audible signal when a key is rejected. [Functionality test 3.3.4] | ||
3.4. BounceKeys | 3.4.1. Provide an audible signal when a key is rejected. [Functionality test 3.4.1] | |
3.5. ToggleKeys | 3.5.1. Provide an audible signal when a locking key is locked or unlocked. [Functionality test 3.5.1] | |
4. For systems with a pointing device, provide the ability to manipulate the pointer from the keyboard. | 4.1. MouseKeys | 4.1.1. Move the pointer via key press. [Functionality test 4.1.1] |
4.1.2. Activate the active mouse button via a key press (e.g., single and double click). [Functionality test 4.1.2] | ||
4.1.3. Change the active mouse button via a key press. [Functionality test 4.1.3] | ||
4.1.4. Hold down a pointer button via a keypress. [Functionality test 4.1.4] | ||
4.1.5. If the system supports multiple pointer buttons, allow multiple pointer buttons to be pressed at the same time. [Functionality test 4.1.5] |
This section and its sub-sections are normative
The following sub-sections provide more detailed descriptions of how the various keyboard access features and functionality should operate from a user interaction standpoint.
This section is normative
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 U.S. 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:
When the user physically presses and releases a modifier key, the modifier logically latches ("sticks") down even though the user has released the modifier key.
The modifier will stay in this latched state until a non-modifier key has been pressed. When a non-modifier key has been pressed, the latched modifier key(s) will automatically unlatch and will revert to the unmodified state when the non-modifier key is released. The net effect is as if the user were holding the modifier key(s) down in conjunction with the non-modifier key.
A user may lock a modifier by pressing/releasing the modifier key twice in a row.
When a modifier is locked, it is as though it has been permanently latched and will not be automatically unlatched when a non-modifier key has been pressed. To unlock a modifier, the user must press the modifier key a third time, which places the modifier in an unlatched and unlocked state.
This section is normative
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 the pointer and its functionality from the keyboard.
When MouseKeys is enabled, the system must behave as follows:
This section is normative
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.
This section is normative
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.
This section is normative
BounceKeys requires a delay (the "debounce time") between keystrokes before accepting the next press of the same key, 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.
This section is normative
ToggleKeys notifies users when they have locked and unlocked a "self locking" key on the keyboard. Target users are people with reduced or no sight. Examples of "self locking" keys include the "Caps Lock", "Num Lock", and "Scroll Lock" keys.
When ToggleKeys is enabled, the system will provide the user with audible notification when a self locking key is locked or unlocked, preferably with unique signals that indicate whether the key has become locked or unlocked. Note that there is a distinction between keys that are locked/unlocked via StickyKeys and "self locking" keys. StickyKeys is used for keys that are not "self locking". As such, when a key is locked or unlocked via StickyKeys, ToggleKeys should not provide audible notification of the event.
This section is normative
http://a11y.org/kafs-gta
http://www.rfc-editor.org/rfc/rfc2119.txt
http://refspecs.linux-foundation.org/X11/XKBlib.ps
http://refspecs.linux-foundation.org/X11/XKBlib.pdf
webmaster@a11y.org
.
Please submit comments, corrections, and/or errata to
acessibility-rfc@a11y.org
, a publicly archived
list.