Re: Action: Keyboard trap

Hi Simon,

The reason for the UI/content distinction is that I think we can assign 
developers have full responsibility for their UI (before plugins and 
extensions), but in the content, depending on how they hand-off control 
of key processing, they might lose control of TAB for example to an 
author's widget that uses that key.

I like the "restore keyboard focus to a known location" part which 
originally came from Kelly because (a) it is a workable "last resort" to 
escape from a keyboard trap and (b) if a commonly used location, such as 
the address bar, is chosen, the user will likely be familiar with the 
key command even without the documentation (which of course is still 
needed as you say).

Cheers,
Jan


Simon Harper wrote:
> Yes this is a very good point - let me clarify - I was thinking along 
> the lines of the standard and non standard keys mentioned and that the 
> documentation point is covered in principle 5 (I think).
> 
> So, do you not think we could modify this to say:
> 
> 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 the 
> same key combinations which enabled the focus or by follow appropriate 
> operating system conventions. In both cases conformance to Principle 
> 5.3. is mandatory.
> 
> Is there not a better way to say this without the UI/Content 
> distinction?  Also, do you think the the AA level suggested means that 
> developers will have more problems implementing this aspect?
> 
> 
> 
> 
>>>> 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
> 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
> +---------------------------------------------------------------------------------+ 
> 
> 
> 
> 

-- 
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 Tuesday, 5 August 2008 14:37:09 UTC