Add two notes/clarifications to 2.1.1/2.1.3 understanding (#1642)

Add clarifications about 2.1.1 and what it specifically does *not* currently require, normatively. Cross-reference to the original discussion a while ago #857 Related discussion #872 --------- Co-authored-by: Mike Gower <mikegower@gmail.com> Co-authored-by: Detlev Fischer <df@3needs.org> Co-authored-by: chaals <chaals@users.noreply.github.com>
w3c · Feb 14, 2024 · a52aac1 · a52aac1
1 parent 4e37e36
commit a52aac1
Show file tree

Hide file tree

Showing 2 changed files with 61 additions and 5 deletions.
diff --git a/understanding/20/keyboard-no-exception.html b/understanding/20/keyboard-no-exception.html
@@ -22,14 +22,41 @@ <h2>In brief</h2>
       <h2>Intent of Keyboard (No Exception)</h2>
 
 
-      <p>The intent of this Success Criterion is to ensure that 
+      <p>The intent of this Success Criterion is to ensure that
          <strong>all</strong> 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.
       </p>
+
+      <div class="note">
+         <p>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 <em>best practice</em>, content
+            should follow the platform/user agent conventions. However, deviating from these
+            conventions does <em>not</em> fail the normative requirement of this Success Criterion.</p>
+         <p>
+            For instance, buttons that have focus can generally be activated using both the
+            <kbd>Enter</kbd> key and the <kbd>Space</kbd> bar. If a custom button control
+            in a web application instead only reacts to <kbd>Enter</kbd>
+            (or even a completely custom key or key combination), this still
+            <strong>satisfies</strong> the requirements of this Success Criterion.
+         </p>
+      </div>
+
+      <div class="note">
+         <p>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 <strong>not</strong> fail the Success Criterion.
+         </p>
+      </div>
 
    </section>
 

diff --git a/understanding/20/keyboard.html b/understanding/20/keyboard.html
@@ -50,8 +50,7 @@ <h2>Intent of Keyboard</h2>
          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 @@ <h2>Intent of Keyboard</h2>
 
       </p>
 
+      <div class="note">
+         <p>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 <em>best practice</em>, content
+            should follow the platform/user agent conventions. However, deviating from these
+            conventions does <em>not</em> fail the normative requirement of this Success Criterion.</p>
+         <p>
+            For instance, buttons that have focus can generally be activated using both the
+            <kbd>Enter</kbd> key and the <kbd>Space</kbd> bar. If a custom button control
+            in a web application instead only reacts to <kbd>Enter</kbd>
+            (or even a completely custom key or key combination), this still
+            <strong>satisfies</strong> the requirements of this Success Criterion.
+         </p>
+      </div>
+
+      <div class="note">
+         <p>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 <strong>not</strong> fail the Success Criterion.
+         </p>
+      </div>
 
    </section>
    <section id="benefits">
@@ -115,8 +140,12 @@ <h2>Examples of Keyboard</h2>
          <dd>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.</dd>
+        <dt>Example 7: Simple search form with pointer-operable submit button</dt>
+        <dd>A search form includes a text input field followed by a submit button. The submit button itself
+               has been coded so that it does <em>not</em> receive focus, and can only be activated using a pointer input.
+               However, since keyboard users can submit the search by pressing <kbd>Enter</kbd> in the text input
+               after typing their search terms, the form passes this Success Criterion.</dd>
       </dl>
-
    </section>
 
    <section id="resources">