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

Re: When is a keyboard trap a keyboard trap

From: Chaals McCathieNevile <w3b@chaals.com>
Date: Fri, 10 Aug 2012 13:00:35 +0200
Cc: "W3C WAI ig" <w3c-wai-ig@w3.org>
To: "Harry Loots" <harry.loots@ieee.org>, "Vivienne CONWAY" <v.conway@ecu.edu.au>
Message-ID: <op.witni9fm22x22q@any.yandex.ru>
On Fri, 10 Aug 2012 12:31:11 +0200, Vivienne CONWAY <v.conway@ecu.edu.au>
wrote:

> Thanks for that Harry
>
> I'll be interested in what the others say also.  I'm also wondering how  
> you advise the user that a new window has been opened (or will be  
> opened) and how they can tab (or if they can tab) to the control you  
> provide.  Do you provide instructions on how to close the pop-up?

The case of a new tab opening in the browser is something I believe
browsers handle reasonably well, and users generally figure out what is
going on.

Most of the Web ago Opera implemented pop-up suppression, to the delight
of users, and it was widely adopted in browsers. Authors responded with
"lightboxes" - an effect within the page equivalent to opening a new
window/tab which normal popup blocking can't trap.

So making sure those don't have accessibility issues is the responsibility
of the author.

And here I suspect I disagree with Harry. In particular you should *not*
use javascript to detect "standard keys fopr closing popups". Apart from
still being unreliable, it makes a lot of assumptions about how the user
has set up their system - assumptions that run a *very* high risk of being
seriously wrong for some proportion of systems. As a general principle
while it often seems like a good idea to help users by providing them with
a consistent interface to your app, this only works if they use your app's
interface more than their browser's. And this is unlikely to happen.

Adding an accesskey would be a great idea - although implementations are  
still bad, they are no longer destructive for the most part. Having a  
tabindex setup that matches what you have done to the user is also  
helpful. And naturally, you should have a button/link to close the 'popup'  
- preferably easy to understand and based on conventional design and  
terminology.

cheers

Chaals

> Regards
>
> Vivienne L. Conway, B.IT(Hons), MACS CT, AALIA(cs)
> PhD Candidate & Sessional Lecturer, Edith Cowan University, Perth, W.A.
> Director, Web Key IT Pty Ltd.
> v.conway@ecu.edu.au<mailto:v.conway@ecu.edu.au>
> v.conway@webkeyit.com<mailto:v.conway@webkeyit.com>
> Mob: 0415 383 673
>
> This email is confidential and intended only for the use of the  
> individual or entity named above. If you are not the intended recipient,  
> you are notified that any dissemination, distribution or copying of this  
> email is strictly prohibited. If you have received this email in error,  
> please notify me immediately by return email or telephone and destroy  
> the original message.
>
> ________________________________
> From: harry.loots@googlemail.com [harry.loots@googlemail.com] On Behalf  
> Of Harry Loots [harry.loots@ieee.org]
> Sent: Friday, 10 August 2012 6:11 PM
> To: Vivienne CONWAY
> Cc: W3C WAI ig
> Subject: Re: When is a keyboard trap a keyboard trap
>
> Hi Vivienne
> I'll attempt to answer this...
>
> I think that the origin of this guideline probably stems from the fact  
> that in earlier versions of Flash (and other technologies), once it had  
> received focus, it was not possible to tab out of it, and return to the  
> parent HTML page.
>
> In later versions of Flash one had to physically programme a keystroke  
> event, which alowed the user to exit (tab out of) the Flash component  
> and return focus to the parent HTML.
>
> Thus: providing a way for a user to tab in and tab out of technologies  
> such as Acrobat, if these are embedded in an HTML page, is essential.  
> Failure to do so, creates a keyboard trap, and the only way out at times  
> is to close the browser window and start again.
>
>
> Insofar as pop-ups are concerned:
>
> "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."
>
>
>  *   Pop-up windows open in a variety of ways - new windows, new tabs.
>
>     *   Ctrl-W closes the active tab  or window if there is only one tab  
> present
>     *   Alt-F4 will close the browser, including all tabs if there are  
> tabs present, and may warn you if you have set your browser up to do so,  
> that you are about to close all tabs (this is an explicit setting in  
> Options->Tabs)
>
>  *   The above is true for IE, as well as FF, etc. If there's only one  
> tab present, then Alt-F4 = Ctrl-W will do the same thing.
>
>
>  *   If the "pop-up" is a new browser that opens above the existing  
> (parent) browser, then as long as the pop-up remains in focus  
> Alt-F4/Ctrl-W will close the pop-up.
>  *   Sometimes what appears to be a pop-up is actually a <DIV> which is  
> displayed above the existing parent. In this case, Alt-F4/Ctrl-W will  
> attempt to close the parent.
>
>
> I would design all pop-ups with a close or cancel function, which closes  
> the pop-up.
>
> Shortcut keys will work as long as they belong to, and are actively  
> programmed to close the intended pop-up. Thus, if a shortcut key is  
> assigned to the parent, and a dialogue is displayed, and the user thinks  
> that the shortcut key to close the window will shut the pop-up  
> (dialogue), then they may be surprised when the browser is closed  
> instead.
>
> Assign shortcut keys specific to the task and make sure the commands are  
> clear. E.g.: [Alt-n] Closes browser (this would be something like  
> window.close), [Alt-x] closes dialogue (this could be something like  
> getElementByID(ID).style.display=none)
>
>
> I hope that helps
>
> Kind regards
>
> Harry
>
>
> On 10 August 2012 07:59, Vivienne CONWAY  
> <v.conway@ecu.edu.au<mailto:v.conway@ecu.edu.au>> wrote:
> Hi all
>
> Seeing you're all so good at answering questions, I'm wondering when  
> something is truly a keyboard trap - the definitions seem to vary a lot.
>
> 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.
>
>
> Regards
>
> Vivienne L. Conway, B.IT<http://B.IT>(Hons), MACS CT, AALIA(cs)
> PhD Candidate & Sessional Lecturer, Edith Cowan University, Perth, W.A.
> Director, Web Key IT Pty Ltd.
> v.conway@ecu.edu.au<mailto:v.conway@ecu.edu.au>
> v.conway@webkeyit.com<mailto:v.conway@webkeyit.com>
> Mob: 0415 383 673
>
> This email is confidential and intended only for the use of the  
> individual or entity named above. If you are not the intended recipient,  
> you are notified that any dissemination, distribution or copying of this  
> email is strictly prohibited. If you have received this email in error,  
> please notify me immediately by return email or telephone and destroy  
> the original message.
> ________________________________________
> From: pigsotwing@gmail.com<mailto:pigsotwing@gmail.com>  
> [pigsotwing@gmail.com<mailto:pigsotwing@gmail.com>] On Behalf Of Andy  
> Mabbett [andy@pigsonthewing.org.uk<mailto:andy@pigsonthewing.org.uk>]
> Sent: Friday, 10 August 2012 1:07 AM
> To: W3C WAI ig
> Subject: Re: Limit on the links in a page
>
> On 9 August 2012 15:06,  <accessys@smart.net<mailto:accessys@smart.net>>  
> wrote:
>
>> my mind boggles at why so many links.
>
> Tables of data; indices, references/ citations, lists, whole-year
> calendars, etc.
>
> For example, there are around 170 in the 'Notes' section of today's
> "featured article" on the English-language Wikipedia:
>
>    http://en.wikipedia.org/wiki/Western_Ganga_Dynasty#Notes
>
>  and far more than 200 in the whole article.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> This e-mail is confidential. If you are not the intended recipient you  
> must not disclose or use the information contained within. If you have  
> received it in error please return it to the sender via reply e-mail and  
> delete any record of it from your system. The information contained  
> within is not the opinion of Edith Cowan University in general and the  
> University accepts no liability for the accuracy of the information  
> provided.
>
> CRICOS IPC 00279B
>
>
>
>
> ________________________________
> This e-mail is confidential. If you are not the intended recipient you  
> must not disclose or use the information contained within. If you have  
> received it in error please return it to the sender via reply e-mail and  
> delete any record of it from your system. The information contained  
> within is not the opinion of Edith Cowan University in general and the  
> University accepts no liability for the accuracy of the information  
> provided.
>
> CRICOS IPC 00279B
>
>


-- 
Chaals - standards declaimer
Received on Friday, 10 August 2012 11:01:01 UTC

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