Re: When is a keyboard trap a keyboard trap

Actually we fully agree on  "In particular you should *not* use javascript
to detect "standard keys fopr closing popups"."

My point was that if a dialogue (or lightbox) appears, that this should
have a shortcut key assigned which will only work with the dialogue; thus
resetting to dialogue to 'display  =  none'. Whereas, if the shortcut key
is assigned the browser window/tab, then it should be (for example)
window.close.

Regards, Harry


On 10 August 2012 13:00, Chaals McCathieNevile <w3b@chaals.com> wrote:

> 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@ecu.edu.au>>
>> v.conway@webkeyit.com<mailto:v**.conway@webkeyit.com<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 <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@ecu.edu.au>>
>> v.conway@webkeyit.com<mailto:v**.conway@webkeyit.com<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:pi**gsotwing@gmail.com<pigsotwing@gmail.com>>
>> [pigsotwing@gmail.com<mailto:p**igsotwing@gmail.com<pigsotwing@gmail.com>>]
>> On Behalf Of Andy Mabbett [andy@pigsonthewing.org.uk<**mailto:
>> andy@pigsonthewing.org.**uk <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:acc**essys@smart.net<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<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
>