Update keyboard to remove normative acceptance of "completely custom …

understanding/20/keyboard-no-exception.html

@@ -21,14 +21,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>
 

understanding/20/keyboard.html

@@ -69,6 +69,31 @@ <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> always 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>, 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 through the keyboard interface.
+            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">