W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2008

Action: Keyboard trap

From: Jim Allan <jimallan@tsbvi.edu>
Date: Wed, 30 Jul 2008 11:37:45 -0500
To: <w3c-wai-ua@w3.org>
Message-ID: <051c01c8f262$98a9a2b0$c9fce810$@edu>

Action: reword/clarify No keyboard trap. The user agent provides at least
one hot key to restore keyboard focus to a known location.

This is a UAAG version of WCAG 2.1.2 No Keyboard Trap: If keyboard focus can
be moved to a component of the page using a keyboard interface, then focus
can be moved away from that component using only a keyboard interface, and,
if it requires more than unmodified arrow or tab keys, the user is advised
of the method for moving focus away. (Level A) [1]

The UAAG version is a repair function for ill behaved embedded User Agents
or author created content. I think it is ultimately the top-level user
agents responsibility to regain keyboard focus regardless of whether the
author does or does not provide information to the user about how to move
the focus back to the main content.

Although, UAWG tries to tersify with great zeal, this item may need some
expansion to be clear. This is a clear example. In UAAG20, the original
wording was:
<original>
4.1.3 No Keyboard Trap: If focus can be moved to a component with the
keyboard, then at least one of the following is true: 
    (a) standard keys: focus can be moved away from the component with the
keyboard using standard navigation keys (i.e., unmodified arrow or tab
keys), or
    (b) documented non-standard keys: focus can be moved away from the
component with non-standard keys and the user is advised of the method.
</original>

After several rounds of group tersification, we arrived at: 
<tersified>
No keyboard trap. The user agent provides at least one hot key to restore
keyboard focus to a known location.
</tersified>

We need some expansion for clarity. I think the main principle of this
success criteria is:
The user agent can grab/regain the focus from embedded user agent through a
known documented key command. 

<proposed> 
4.1.3 No Keyboard Trap: If focus can be moved to a component with the
keyboard, then at least one of the following is true: 
    (a) standard keys: focus can be moved away from the component with the
keyboard using standard navigation keys (i.e., unmodified arrow or tab
keys), or
    (b) documented key command: focus can be moved away from the component
with a documented key command.
</proposed>
Implicit in this Success Criteria, which should be written in the
techniques, is that the focus should move to next or previous actionable
item, as determined by user input (tab or shift-tab), in the main content
tree.  

1.
http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/keyboard-operatio
n-trapping.html 

Jim Allan, Accessibility Coordinator & Webmaster 
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Wednesday, 30 July 2008 16:43:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:52:01 GMT