Re: Action: Keyboard trap

This is one of those times that the content/UI distinction comes into 
play - a TAB keyboard trap in the tool's UI is unacceptable, but it is 
more acceptable in the content as long as another way out is provided. 
That said, we might want to require standard navigation keys at a 
different level.

So...how about:

A: No Keyboard Trap (Minimum): The user agent prevents keyboard traps as 
follows:
(a) in the UI: if keyboard focus can be moved to a component using the 
keyboard, then focus can be moved away from that component using 
standard sequential keyboard commands (e.g., TAB key)
(b) in the rendered content: provides a documented direct keyboard 
command that will always restore keyboard focus to a known location 
(e.g., the address bar).

AA: No Keyboard Trap (Enhanced): In the rendered content, if keyboard 
focus can be moved to a component using the keyboard, then focus can be 
moved away from that component using standard sequential keyboard 
commands (e.g., TAB key).

Cheers,
Jan


Jim Allan wrote:
> 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
> 
> 
> 
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information (i-school)
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Friday, 1 August 2008 14:16:09 UTC