Re: Action: Keyboard trap

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
>
>
>

Received on Friday, 1 August 2008 16:18:01 UTC