Open A11y.org (The Linux Foundations' Accessibility Work Group

Keyboard Access Functional Specification, RC3

Authors:
Earl Johnson, Sun Microsystems, Inc.
Bill Haneman, Sun Microsystems, Inc.
Mark Novak, University of Wisconsin, Madison
Gunnar Schmidt, KDE Accessibility
Willie Walker, Sun Microsystems, Inc.
Editors:
Earl Johnson, Chair, Open A11y Workgroup's Keyboard Special Interest Group
Gregory J. Rosmaita, Vice-Chair, Open Accessibility
Janina Sajka, Chair, Open Accessibility
editor emeritus: George Kraft IV, IBM
Table of Contents
1. What This Specification Defines
2. Scope
3. Functional Specification

This specification is copyright 2005, 2008 Open Accessibility (A11y) at The Linux Foundation. All Rights Reserved.


Abstract

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.

About This Document

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.



What This Specification Defines

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:


Limitations

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.


Conformance Requirements

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.


Submitting Feedback and Reporting Errata

This section is informative

A list of known errors in this specification is maintained at:
http://accessibility.linux-foundation.org/a11yspecs/kbd/updates/kafs-rc3-errata.html
Please report errors in this document to 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.


Features

This section is normative

The features defined in this specification provide the user with the following type of support:



Scope

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.



Functional Specification

This section is normative

Configuration and Setting Requirements

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.

Table 1. Configuration and Setting Requirements
Feature Functionality Type of Control Option's Variable Ranges
Notes:
a. Common practice today is this functionality turns off all the keyboard access features. This specification only requires that this boolean control affect the SlowKeys and StickyKeys features, in line with what the XKB specification in the X Windows System provides.
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.

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

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.

Table 2. End-User Notification, Keyboard Invocation, and Pointer Emulation Requirements
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]

Feature Behavior Requirements

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.


StickyKeys

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 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.

    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.

  • A user may lock more than one modifier at a time.
  • Any latched or locked modifiers will also be used in conjunction with pointer events.
  • Pressing pointer buttons will result in the same behavior as pressing a non-modifier key.

MouseKeys

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:

  • When the user presses and holds a key for moving the pointer's 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" pointer's 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., sequential button press and release events) using the current "active" button.
  • 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.
  • When the user presses the key for holding down a button, the system will generate a button press event using the current "active" button. 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 pointer 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.
  • More than one pointer button can be logically pressed at a time.

RepeatKeys

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.


SlowKeys

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.


BounceKeys

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.


ToggleKeys

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.



Normative References

This section is normative

[KAFS GTA]
Generic Assertions for Manual Testing of Keyboard Functional Access (KAFS GTA); edited by Johnson, Earl; Rosmaita, Gregory J.; Sajka, Janina, and Gunnar Schmidt; authors: Johnson, Earl; Hanneman, Bill; Novak, Mark, and Walker, Willie. 2008.
Available at: http://a11y.org/kafs-gta
[RFC2119]
Key words for use in RFCs to indicate requirement levels, RFC 2119, S. Bradner, March 1997.
Available at: http://www.rfc-editor.org/rfc/rfc2119.txt
[XKB]
XKB: The X Keyboard Extension, Revision 6.4 (PostScript file)
Available from: http://refspecs.linux-foundation.org/X11/XKBlib.ps
[XKBlib]
The X Keyboard Extension: Library Specification Library (X Version 11, Release 6.4) [PDF file] An X Consortium Standard. Version 1.0/Document Revision 1.1. Edited by Aitken, Gary and Benson, Amber J.; authors: Fortune, Erik; Converse, Donna; Sachs, George; Walker, Will.
Available from: http://refspecs.linux-foundation.org/X11/XKBlib.pdf
Copyright 2005-2008, Open Accessibility at The Linux Foundation. All Rights Reserved.

Please address any technical problems encountered with this document to webmaster@a11y.org. Please submit comments, corrections, and/or errata to acessibility-rfc@a11y.org, a publicly archived list.

Valid XHTML 1.0 Strict (check for yourself!) Web-Content Accessibility Guidelines, Level Triple-A Compliant W3C Validated Cascading Style Sheets!