diff --git a/understanding/20/keyboard-no-exception.html b/understanding/20/keyboard-no-exception.html index 6d755d62f4..ed57ae6585 100644 --- a/understanding/20/keyboard-no-exception.html +++ b/understanding/20/keyboard-no-exception.html @@ -22,14 +22,41 @@

In brief

Intent of Keyboard (No Exception)

-

The intent of this Success Criterion is to ensure that +

The intent of this Success Criterion is to ensure that all content is operable from the keyboard. This is the same as Success Criterion 2.1.1, except that no exceptions are allowed. This does not mean that content where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (excluded from the requirements of 2.1.1) must be made keyboard accessible. Rather, it means that content that uses path-dependent input cannot conform to this - Success Criterion and therefore cannot meet Guideline 2.1 at Level AAA. + Success Criterion and therefore cannot meet Guideline 2.1 at Level AAA.

+ +
+

Platforms and user agents usually have conventions for how web content or + applications are controlled with a keyboard interface. If content does not follow + the platform/user agent conventions it may be difficult to use, as users will need + to learn different interaction methods. As a best practice, content + should follow the platform/user agent conventions. However, deviating from these + conventions does not fail the normative requirement of this Success Criterion.

+

+ For instance, buttons that have focus can generally be activated using both the + Enter key and the Space bar. If a custom button control + in a web application instead only reacts to Enter + (or even a completely custom key or key combination), this still + satisfies the requirements of this Success Criterion. +

+
+ +
+

This Success Criterion does not require that every visible control that can be activated + using a pointer (such as a mouse or touch screen input) must also be focusable and actionable using the keyboard. + The normative requirement is only that there must be a way for keyboard interface users to perform + the same, or comparable, actions and to operate the content. Generally, the easiest way + to achieve this is to provide controls that can be operated with all possible input devices; + however, if a web application implements a separate mode of operation for keyboard interface users, + it will not fail the Success Criterion. +

+
diff --git a/understanding/20/keyboard.html b/understanding/20/keyboard.html index 6d5572defd..9ec62e644f 100644 --- a/understanding/20/keyboard.html +++ b/understanding/20/keyboard.html @@ -50,8 +50,7 @@

Intent of Keyboard

example, clicking, selecting, moving, sizing). However, there is a small class of input that is done with a pointing device that cannot be done from the keyboard in any known fashion without requiring an inordinate number of keystrokes. Free hand - drawing, watercolor painting, and flying a helicopter through an obstacle course are - all examples of functions that require path dependent input. Drawing straight lines, + drawing, or watercolor painting require path dependent input. Drawing straight lines, regular geometric shapes, re-sizing windows and dragging objects to a location (when the path to that location is not relevant) do not require path dependent input. @@ -69,6 +68,32 @@

Intent of Keyboard

+
+

Platforms and user agents usually have conventions for how web content or + applications are controlled with a keyboard interface. If content does not follow + the platform/user agent conventions it may be difficult to use, as users will need + to learn different interaction methods. As a best practice, content + should follow the platform/user agent conventions. However, deviating from these + conventions does not fail the normative requirement of this Success Criterion.

+

+ For instance, buttons that have focus can generally be activated using both the + Enter key and the Space bar. If a custom button control + in a web application instead only reacts to Enter + (or even a completely custom key or key combination), this still + satisfies the requirements of this Success Criterion. +

+
+ +
+

This Success Criterion does not require that every visible control that can be activated + using a mouse or touch screen must also be focusable and actionable using the keyboard. + The normative requirement is only that there must be a way for keyboard interface users to perform + the same, or comparable, actions and to operate the content. Generally, the easiest way + to achieve this is to provide controls that can be operated with all possible input devices; + however, if a web application implements a separate mode of operation for keyboard interface users, + it will not fail the Success Criterion. +

+
@@ -115,8 +140,12 @@

Examples of Keyboard

A PDA device that is usually operated via a stylus has an optional keyboard that can be attached. The keyboard allows full Web browsing in standard fashion. The Web content is operable because it was designed to work with keyboard-only access.
+
Example 7: Simple search form with pointer-operable submit button
+
A search form includes a text input field followed by a submit button. The submit button itself + has been coded so that it does not receive focus, and can only be activated using a pointer input. + However, since keyboard users can submit the search by pressing Enter in the text input + after typing their search terms, the form passes this Success Criterion.
-