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

Re: When is a keyboard trap a keyboard trap

From: Ramón Corominas <listas@ramoncorominas.com>
Date: Fri, 10 Aug 2012 13:32:09 +0200
Message-ID: <5024F139.7020801@ramoncorominas.com>
To: Vivienne CONWAY <v.conway@ecu.edu.au>
CC: W3C WAI ig <w3c-wai-ig@w3.org>
Hi, Vivienne and all,

SC 2.1.2 states:

"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 or other standard exit methods, 
the user is advised of the method for moving focus away. (Level A) "

This means:

a) The SC is only related to components within a page, not to new pages 
opened through pop-ups or new windows/tabs (that is, "changes of context").

b) It is required that the user moved to the component using the 
keyboard. For example, this doesn't apply if the only way to access a 
Flash movie is by clicking on it; if you were able to do so, it is 
reasonable to assume that you will also be able to click outside the 
Flash movie.

c) I guess that "other standard exit methods" refers to the fact that 
other methods could be available in the future, or maybe are already 
available with some types of switches or other special input devices; I 
don't know how they work now, but AT could use special keys or gestures 
to move through focusable elements. In reality, I think this goes beyond 
"keyboard" accessibility, but device-independence (I still don't 
understand why this concept was abandoned in WCAG 2.0 in favour of this).

For example, imagine a user with motor disability that might use a 
single-button switch to jump through the links, and then double-press to 
access the link (just an hypothesis). Or, in an i-Device, you can "tab" 
through links using flip right/flip left gestures. So if a link gains 
focus through this gestures, the same gestures should be enough to go to 
the next/previous focusable elements. Indeed, this is a big issue when 
you are trying to read an article and VoiceOver stops reading without 
reason and there is no way to continue reading (unless you find the next 
sentence with your finger, which can be really difficult sometimes).

Hope this helps, kind regards,
Ramón.

Vivienne said:

> 2.1.2. states that if the keyboard focus can be moved to a component of the page, then you need to be able to move that focus away from that component solely by the keyboard as well.  and "If it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away".
> 
> My question involves what "standard exit methods" this assumes.
> 
> Pop-up windows open in a variety of ways - new windows, new tabs.  Media players pop up from links and then the user has trouble closing them (if they even know they are in a new window).  Sometimes you can get out by Ctrl+W, or Alt+F4, and sometimes trying one of these causes lots of other problems.  It also depends upon what browser you're using.  For example in IE9, both Ctrl+W and Alt+F4 do the same thing, while in Firefox Alt+F4 displays a warningsaying do you want to close all tabs.  Also, sometimes closing the popup by a keyboard shortcut may close the browser which is a huge problem.
> 
> How do you decide what a "standard exit method" is?  There are quite a few lists, but many users aren't even aware of these shortcuts.  I'd personally like to see people provide an annoucement that the new window is opening and telling the user how to get back again, but I can't see that happening across the board.  For example, that's a lot of information to attach to a Twitter widget that's set to open a new window.
> 
> I appreciate your thoughts.
Received on Friday, 10 August 2012 11:32:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:30 UTC