E-mail List Archives
Thread: Keyboard trap for non-modal dialogs and popups:
Number of posts in this thread: 15 (In chronological order)
From: Ramakrishnan Subramanian
Date: Thu, Sep 22 2016 4:29AM
Subject: Keyboard trap for non-modal dialogs and popups:
No previous message | Next message →
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a
non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the
focus inside the popup.
Generally the mouse user is able to access the parent page and also
the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
From: JP Jamous
Date: Thu, Sep 22 2016 6:10AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
Hmm, trapping me inside a modal. I don't think I like the approach Ramakrishnan. The only way I would approve it is if I have a way of getting out.
Think of this.
You trap me inside the modal and I device to press Insert + 7 to pull the list of links on the page, because I decided to go somewhere else. What if JAWS cannot get out of this modal?
Can't you use proper semantic and put the cursor at the top of the modal and let the browser handle the tabindex and navigation?
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 5:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
From: Lovely, Brian (CONT)
Date: Thu, Sep 22 2016 6:55AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
JP, I support the trapping in a modal to an extent, as it seems to provide an experience analogous to that of a sighted user. For a sighted user, using the mouse, a modal opens over a semi-opaque overlay that blocks all interaction with the rest of the page until the user dismisses the modal via either the close button or possibly also the escape key. For a non-sighted user, the technique to emulate this is to put all page content in a container, and the modal outside that container. When the modal is opened, that content container is set to aria-hidden="true" to emulate the semi-opaque overlay, and tab and/or arrow keys cycle through the modal contents, hence the "trapping" of focus within the modal. I would think this would be better than being able to move off the end of the modal and possibly having trouble getting back to it, or being unable to quite decide where the modal contents end and page content begins.
The flow would be as follows:
A button or link is encountered that will trigger the modal. It's text and surrounding context communicate that it is for completing some specific task.
The modal opens, and focus is shifted to the modal wrapper. A reference to the triggering element is stored so it can be returned to when the modal is dismissed.
Focus is trapped in the modal.
The user performs the task at hand, or decides not to do so at this time.
The user presses tab or an arrow key to cycle back to the close button and dismisses the modal.
The aria-hidden attribute on the page content is set to "false" and focus is returned to the link or button that originally triggered the modal
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of JP Jamous
Sent: Thursday, September 22, 2016 8:10 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Hmm, trapping me inside a modal. I don't think I like the approach Ramakrishnan. The only way I would approve it is if I have a way of getting out.
Think of this.
You trap me inside the modal and I device to press Insert + 7 to pull the list of links on the page, because I decided to go somewhere else. What if JAWS cannot get out of this modal?
Can't you use proper semantic and put the cursor at the top of the modal and let the browser handle the tabindex and navigation?
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 5:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Jonathan Avila
Date: Thu, Sep 22 2016 6:57AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
> Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
For modals, you would want to trap the focus. For non-modals in my opinion it depends on whether the non-modal overlaps the other page content. If the non-modal slides into place or doesn't significantly cover other content then in my opinion it should not trap focus. The non-modal's boundaries should be communicated via the role dialog with the new aria-modal attribute or through another mechanism such as a region where a name can be assigned and the boundary of the popup will then be exposed to users of assistive technology. If the non-modal covers most of the page but allows the user to click out then we'd really need to examine why this is. For example, is the user expected to review information between the non-modal and the main page content, etc. In some cases a non-modal may really be a sidebar such as a chat window and keeping the focus order in the chat window is actually helpful to the user. But the user would need a way to move focus between the different panes much like the user would do on the Windows desktop with F6. So it depends on how the content is presented and how the user is expected to interact with the non-modal and page content.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 6:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
From: Lovely, Brian (CONT)
Date: Thu, Sep 22 2016 7:02AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
Ah, my response was to JPs message where he specifically said "modal". I completely spaced the subject line which says "non-modal". Yeah, I agree with Jonathan. I'd have to know more about the specific non-modal at hand before I could say whether or not I support trapping focus. There are a lot of expandables, alerts, tooltips, and whatnot that qualify as non-modals.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jonathan Avila
Sent: Thursday, September 22, 2016 8:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
> Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
For modals, you would want to trap the focus. For non-modals in my opinion it depends on whether the non-modal overlaps the other page content. If the non-modal slides into place or doesn't significantly cover other content then in my opinion it should not trap focus. The non-modal's boundaries should be communicated via the role dialog with the new aria-modal attribute or through another mechanism such as a region where a name can be assigned and the boundary of the popup will then be exposed to users of assistive technology. If the non-modal covers most of the page but allows the user to click out then we'd really need to examine why this is. For example, is the user expected to review information between the non-modal and the main page content, etc. In some cases a non-modal may really be a sidebar such as a chat window and keeping the focus order in the chat window is actually helpful to the user. But the user would need a way to move focus between the different panes much like the user would do on the Windows desktop with F6. So it depends on how the content is presented and how the user is expected to interact with the non-modal and page content.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog Check out our Digital Accessibility Webinars!
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 6:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Don Mauck
Date: Thu, Sep 22 2016 11:08AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
Actually keyboard traps are a WCAG violation and should never happen
Snippet: 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)
-----Original Message-----
From: JP Jamous [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, September 22, 2016 6:10 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Hmm, trapping me inside a modal. I don't think I like the approach Ramakrishnan. The only way I would approve it is if I have a way of getting out.
Think of this.
You trap me inside the modal and I device to press Insert + 7 to pull the list of links on the page, because I decided to go somewhere else. What if JAWS cannot get out of this modal?
Can't you use proper semantic and put the cursor at the top of the modal and let the browser handle the tabindex and navigation?
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 5:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
From: Beranek, Nicholas
Date: Thu, Sep 22 2016 11:15AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
WAI-ARIA authoring practices dictate that 'focus must be held within the dialog until it is cancelled or submitted- (http://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal). Note: This is for modal dialogs. Non-modal dialogs should not trap focus and should be able to be dismissed appropriately (see Jonathan's response related to the F6 key and Brian's the escape key).
--
Nick Beranek
Digital Accessibility Team
On 9/22/16, 1:08 PM, "WebAIM-Forum on behalf of Don Mauck" < = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:
Actually keyboard traps are a WCAG violation and should never happen
Snippet: 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)
-----Original Message-----
From: JP Jamous [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, September 22, 2016 6:10 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Hmm, trapping me inside a modal. I don't think I like the approach Ramakrishnan. The only way I would approve it is if I have a way of getting out.
Think of this.
You trap me inside the modal and I device to press Insert + 7 to pull the list of links on the page, because I decided to go somewhere else. What if JAWS cannot get out of this modal?
Can't you use proper semantic and put the cursor at the top of the modal and let the browser handle the tabindex and navigation?
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 5:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: JP Jamous
Date: Thu, Sep 22 2016 11:17AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
That was exactly my thought Don. I wondered if he had a special case though.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Don Mauck
Sent: Thursday, September 22, 2016 12:08 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Actually keyboard traps are a WCAG violation and should never happen
Snippet: 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)
-----Original Message-----
From: JP Jamous [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, September 22, 2016 6:10 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Hmm, trapping me inside a modal. I don't think I like the approach Ramakrishnan. The only way I would approve it is if I have a way of getting out.
Think of this.
You trap me inside the modal and I device to press Insert + 7 to pull the list of links on the page, because I decided to go somewhere else. What if JAWS cannot get out of this modal?
Can't you use proper semantic and put the cursor at the top of the modal and let the browser handle the tabindex and navigation?
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 5:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
From: JP Jamous
Date: Thu, Sep 22 2016 11:27AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
Sorry guys, I did not pay attention to the subject. I was running low on Coffee. LOL
Thanks for pointing that out for me Bryan.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lovely, Brian (CONT)
Sent: Thursday, September 22, 2016 8:02 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Ah, my response was to JPs message where he specifically said "modal". I completely spaced the subject line which says "non-modal". Yeah, I agree with Jonathan. I'd have to know more about the specific non-modal at hand before I could say whether or not I support trapping focus. There are a lot of expandables, alerts, tooltips, and whatnot that qualify as non-modals.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jonathan Avila
Sent: Thursday, September 22, 2016 8:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
> Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
For modals, you would want to trap the focus. For non-modals in my opinion it depends on whether the non-modal overlaps the other page content. If the non-modal slides into place or doesn't significantly cover other content then in my opinion it should not trap focus. The non-modal's boundaries should be communicated via the role dialog with the new aria-modal attribute or through another mechanism such as a region where a name can be assigned and the boundary of the popup will then be exposed to users of assistive technology. If the non-modal covers most of the page but allows the user to click out then we'd really need to examine why this is. For example, is the user expected to review information between the non-modal and the main page content, etc. In some cases a non-modal may really be a sidebar such as a chat window and keeping the focus order in the chat window is actually helpful to the user. But the user would need a way to move focus between the different panes much like the user would do on the Windows desktop with F6. So it depends on how the content is presented and how the user is expected to interact with the non-modal and page content.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog Check out our Digital Accessibility Webinars!
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 6:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
From: Lovely, Brian (CONT)
Date: Thu, Sep 22 2016 11:38AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
Trapping focus in a modal merely means that pressing the tab/arrow keys will cycle you through the modal elements until the modal is dismissed. It is not a keyboard trap in the sense that it is an unescapable dead end.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Don Mauck
Sent: Thursday, September 22, 2016 1:08 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Actually keyboard traps are a WCAG violation and should never happen
Snippet: 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)
-----Original Message-----
From: JP Jamous [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, September 22, 2016 6:10 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Hmm, trapping me inside a modal. I don't think I like the approach Ramakrishnan. The only way I would approve it is if I have a way of getting out.
Think of this.
You trap me inside the modal and I device to press Insert + 7 to pull the list of links on the page, because I decided to go somewhere else. What if JAWS cannot get out of this modal?
Can't you use proper semantic and put the cursor at the top of the modal and let the browser handle the tabindex and navigation?
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 5:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Beranek, Nicholas
Date: Thu, Sep 22 2016 11:32AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
Let's separate the two components from the subject: 1) non-modal dialogs; and 2) popups. Non-modal dialogs should not trap focus. Popups, which I'll call 'modal dialogs-, should. Remember that we're trying to emulate the default behavior in the operating system. Dialog windows do trap focus, as do alerts and confirm boxes. The window.open method which spawns a classical 'popup- traps focus until you navigate away from the window.
We want to create as seamless an experience from OS to browser, so it would make sense to do this for modal dialogs.
--
Nick Beranek
Digital Accessibility Team
On 9/22/16, 1:17 PM, "WebAIM-Forum on behalf of JP Jamous" < = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:
That was exactly my thought Don. I wondered if he had a special case though.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Don Mauck
Sent: Thursday, September 22, 2016 12:08 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Actually keyboard traps are a WCAG violation and should never happen
Snippet: 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)
-----Original Message-----
From: JP Jamous [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, September 22, 2016 6:10 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Hmm, trapping me inside a modal. I don't think I like the approach Ramakrishnan. The only way I would approve it is if I have a way of getting out.
Think of this.
You trap me inside the modal and I device to press Insert + 7 to pull the list of links on the page, because I decided to go somewhere else. What if JAWS cannot get out of this modal?
Can't you use proper semantic and put the cursor at the top of the modal and let the browser handle the tabindex and navigation?
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 5:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Don Mauck
Date: Thu, Sep 22 2016 11:42AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
Well, that's what I thought from a modal point, however, the way I read the message was that he was planning on making a trap.
-----Original Message-----
From: Lovely, Brian (CONT) [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, September 22, 2016 11:39 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Trapping focus in a modal merely means that pressing the tab/arrow keys will cycle you through the modal elements until the modal is dismissed. It is not a keyboard trap in the sense that it is an unescapable dead end.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Don Mauck
Sent: Thursday, September 22, 2016 1:08 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Actually keyboard traps are a WCAG violation and should never happen
Snippet: 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)
-----Original Message-----
From: JP Jamous [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, September 22, 2016 6:10 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Hmm, trapping me inside a modal. I don't think I like the approach Ramakrishnan. The only way I would approve it is if I have a way of getting out.
Think of this.
You trap me inside the modal and I device to press Insert + 7 to pull the list of links on the page, because I decided to go somewhere else. What if JAWS cannot get out of this modal?
Can't you use proper semantic and put the cursor at the top of the modal and let the browser handle the tabindex and navigation?
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 5:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
From: Don Mauck
Date: Thu, Sep 22 2016 11:42AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
Agreed.
-----Original Message-----
From: Beranek, Nicholas [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, September 22, 2016 11:33 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Let's separate the two components from the subject: 1) non-modal dialogs; and 2) popups. Non-modal dialogs should not trap focus. Popups, which I'll call 'modal dialogs-, should. Remember that we're trying to emulate the default behavior in the operating system. Dialog windows do trap focus, as do alerts and confirm boxes. The window.open method which spawns a classical 'popup- traps focus until you navigate away from the window.
We want to create as seamless an experience from OS to browser, so it would make sense to do this for modal dialogs.
--
Nick Beranek
Digital Accessibility Team
On 9/22/16, 1:17 PM, "WebAIM-Forum on behalf of JP Jamous" < = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:
That was exactly my thought Don. I wondered if he had a special case though.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Don Mauck
Sent: Thursday, September 22, 2016 12:08 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Actually keyboard traps are a WCAG violation and should never happen
Snippet: 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)
-----Original Message-----
From: JP Jamous [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, September 22, 2016 6:10 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Hmm, trapping me inside a modal. I don't think I like the approach Ramakrishnan. The only way I would approve it is if I have a way of getting out.
Think of this.
You trap me inside the modal and I device to press Insert + 7 to pull the list of links on the page, because I decided to go somewhere else. What if JAWS cannot get out of this modal?
Can't you use proper semantic and put the cursor at the top of the modal and let the browser handle the tabindex and navigation?
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 5:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Tim Harshbarger
Date: Thu, Sep 22 2016 11:53AM
Subject: Re: Keyboard trap for non-modal dialogs and popups:
← Previous message | Next message →
And there is yet another way to look at this situation.
Typically, all users (whether with or without disabilities) will want or need to perform the same type of tasks or achieve the same goals with a specific user interface. Where users with or without disabilities will tend to differ is in how they perceive, comprehend, or operate those user interfaces.
So, if you have a user interface component (like a non-modal dialog) that allows someone using the mouse to interact with other parts of the user interface, you can assume that people using the keyboard or a screen reader will have the same need or want to access those other user interface components as well.
However, if you prevent someone using a mouse from accessing other components on the user interface (like with a modal dialog), people using the keyboard or a screen reader will likely gain the same benefit from having that same limitation.
There can be exceptions to this rule, but the exceptions tend to be quite obvious when you find them--or you are looking at an issue that directly touches on how people perceive, comprehend, or operate user interfaces.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Beranek, Nicholas
Sent: Thursday, September 22, 2016 12:33 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Let's separate the two components from the subject: 1) non-modal dialogs; and 2) popups. Non-modal dialogs should not trap focus. Popups, which I'll call 'modal dialogs-, should. Remember that we're trying to emulate the default behavior in the operating system. Dialog windows do trap focus, as do alerts and confirm boxes. The window.open method which spawns a classical 'popup- traps focus until you navigate away from the window.
We want to create as seamless an experience from OS to browser, so it would make sense to do this for modal dialogs.
--
Nick Beranek
Digital Accessibility Team
On 9/22/16, 1:17 PM, "WebAIM-Forum on behalf of JP Jamous" < = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:
That was exactly my thought Don. I wondered if he had a special case though.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Don Mauck
Sent: Thursday, September 22, 2016 12:08 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Actually keyboard traps are a WCAG violation and should never happen
Snippet: 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)
-----Original Message-----
From: JP Jamous [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, September 22, 2016 6:10 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Hmm, trapping me inside a modal. I don't think I like the approach Ramakrishnan. The only way I would approve it is if I have a way of getting out.
Think of this.
You trap me inside the modal and I device to press Insert + 7 to pull the list of links on the page, because I decided to go somewhere else. What if JAWS cannot get out of this modal?
Can't you use proper semantic and put the cursor at the top of the modal and let the browser handle the tabindex and navigation?
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ramakrishnan Subramanian
Sent: Thursday, September 22, 2016 5:30 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Keyboard trap for non-modal dialogs and popups:
Dear members
I request for your inputs on the following thing.
Is it a good practice to trap the keyboard focus inside the popup or a non-modal dialog?
I mean, while using arrow keys and tab/shift tab keys, trapping the focus inside the popup.
Generally the mouse user is able to access the parent page and also the popup simultaneously.
Should this be the case for the keyboard only users and screen reader users?
Which approach would be recommendable here?
What are the pros and cons for both the approaches?
Thanks for your inputs
Ramakrishnan
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Dan Smith
Date: Thu, Sep 22 2016 4:14PM
Subject: Re: Keyboard trap for non-modal dialogs and popups
← Previous message | No next message
If you haven't already, check out Greg Krause's Incredible Accessible Modal
Window. I've been following development on and off. At one point he was
relying on aria-hidden to remove everything behind the modal from the tab
order. I'm not sure if there's a more active trapping solution in the
latest version (3) http://gdkraus.github.io/accessible-modal-dialog/
--
Dan Smith
Do The Right Thing.