Expand 2.1.2 understanding to make it more ... understandable

custom-words.txt

@@ -97,3 +97,4 @@ tristimulus
 unsynchronized
 untimed
 untrap
+untrapping

understanding/20/no-keyboard-trap.html

@@ -11,48 +11,64 @@ <h1>Understanding No Keyboard Trap</h1>
    <section id="brief">
 		<h2>In brief</h2>
 		<dl>
-         <dt>Goal</dt><dd>Keyboard users don't get stuck.</dd>
-         <dt>What to do</dt><dd>Ensure users always know how to navigate away from components.</dd>
-         <dt>Why it's important</dt><dd>People who rely on the keyboard often have no other means to navigate.</dd> 
+         <dt>Goal</dt>
+         <dd>Keyboard users don't get stuck.</dd>
+         <dt>What to do</dt>
+         <dd>Ensure users always know how to navigate away from components.</dd>
+         <dt>Why it's important</dt>
+         <dd>People who rely on the keyboard often have no other means to navigate.</dd> 
       </dl>
-
    </section>
 
    <section id="intent">
       <h2>Intent of No Keyboard Trap</h2>
 
-
       <p>The intent of this success criterion is to ensure that that content does not "trap"
          keyboard focus within subsections of content on a web page. This is a common problem
          when multiple formats are combined within a page and rendered using plug-ins or embedded
-         applications.
-      </p>
+         applications, or when custom components and widgets are not implemented with keyboard users
+         in mind.</p>
 
-      <p>There may be times when the functionality of the web page restricts the focus to a
-         subsection of the content, as long as the user knows how to leave that state and "untrap"
-         the focus.
-      </p>
+      <p>There may be times when it's appropriate for a web page to restrict focus to a subsection
+         of the content – for example, when the user is inside a modal dialog or popover. This does
+         not fail the requirements of this criterion, as long as the user knows how to "untrap" the focus
+         and leave that component.</p>
+
+      <p>Keyboard focus is not considered trapped when the user can navigate away from a component
+         using only a keyboard interface, and if it only requires unmodified arrow or <kbd>Tab</kbd> keys
+         or other "standard exit methods". This specification does not define what constitutes a
+         "standard exit method" – this is dependent on the user's hardware, user agent, and operating system,
+         and as such will require some interpretation from authors and auditors.
+         In most desktop environments, pressing the <kbd>Esc</kbd> key is a commonly used "standard exit method".
+         On mobile operating systems, the use of a physical "back" button on the device or external keyboard can
+         be seen as a "standard exit method".</p>
+
+      <p>If untrapping focus requires a different method (rather than unmodified arrow or <kbd>Tab</kbd> keys or
+         other "standard exit methods"), content can still pass this criterion provided that the user is
+         advised how they can untrap focus using their keyboard interface.</p>
 
 
    </section>
    <section id="benefits">
       <h2>Benefits of No Keyboard Trap</h2>
 
-
       <ul>
-
          <li>People who rely on a keyboard or keyboard interface to use the web including people
             who are blind and people with physical disabilities.
          </li>
-
       </ul>
-
    </section>
 
    <section id="examples">
       <h2>Examples of No Keyboard Trap</h2>
 
       <dl>
+         <dt>A modal dialog box</dt>
+         <dd>A web application opens a dialog box. At the bottom of the dialog are two buttons,
+					"Cancel" and "OK". When the dialog is open, focus is trapped within the dialog –
+					tabbing from the last control in the dialog takes focus to the first control in the
+					dialog. The dialog is dismissed by activating the "Cancel" button, the "OK" button,
+               or the <kbd>Esc</kbd> key.</dd>
          <dt>A calendar widget</dt>
          <dd>A calendar widget allows users to add, remove or update items in their calendar using
                the keyboard. The controls in the widget are part of the tab order within the web
@@ -62,20 +78,11 @@ <h2>Examples of No Keyboard Trap</h2>
          <dd>Once a user tabs into an applet, further tabs and other keystrokes are handled by
                the applet. Instructions describing the keystroke used to exit the applet are provided
                prior to the applet as well as within the applet itself.</dd>
-         <dt>A modal dialog box</dt>
-         <dd>A web application brings up a dialog box. At the bottom of the dialog are two buttons,
-               Cancel and OK. When the dialog has been opened, all web page content outside the dialog becomes 
-               inert and cannot receive focus (though, depending on implementation, the focus cycle
-               might still include user agent controls).
-               The dialog is dismissed by activating the Cancel button or the OK button.</dd>
       </dl>
-
    </section>
 
    <section id="resources">
       <h2>Resources for No Keyboard Trap</h2>
-
-
    </section>
 
    {% # Data for associated techniques is defined in understanding/understanding.11tydata.js %}