Re: Action: Keyboard trap

Hi Simon,

What's the appropriate key combination for WindowsXP to move focus from 
a widget that is trapping the TAB and arrow keys?

-Jan



Simon Harper wrote:
> Hi there,
> 
> I wasn't really sure why we needed to do anything that the OS didn't 
> support or why we need to have a documented section if we have 5.3?
> 
> 
> <proposed>
> 4.1.3 No Keyboard Trap: If focus can be moved to a component with the 
> keyboard, then focus can be moved away from that component using key 
> combinations which follow appropriate operating system conventions and 
> confirm to Principle 5.3.
> </proposed>
> 
> 
> 
> Cheers
> Si.
> 
> ====
> Simon Harper
> University of Manchester (UK)
> 
> Human Centred Web Lab: http://hcw.cs.manchester.ac.uk
> My Site: http://hcw.cs.manchester.ac.uk/people/harper/
> My Diary (iCal): http://hcw.cs.manchester.ac.uk/diaries/SimonHarper.ics
> 
> 
> +----------------------[ NEW & INTERESTING 
> ]--------------------------------------+
>   ASSETS 2008                . 13-15 Oct 2008 . 
> http://www.sigaccess.org/assets08
> +---------------------------------------------------------------------------------+ 
> 
> 
> 
> 
> 
> On 1 Aug 2008, at 15:15, Jan Richards wrote:
> 
>>
>> 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
>>
>>
>>
> 

-- 
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 17:21:34 UTC