Keyboard trap when using ctools modal

Looks like this might be caused by the ctools modal.js function - moving to ctools.

js/modal.js, line 403-428:

    // Keyboard and focus event handler ensures focus stays on modal elements only
    modalEventHandler = function( event ) {
      target = null;
      if ( event ) { //Mozilla
        target = event.target;
      } else { //IE
        event = window.event;
        target = event.srcElement;
      }

      var parents = $(target).parents().get();
      for (var i = 0; i < parents.length; ++i) {
        var position = $(parents[i]).css('position');
        if (position == 'absolute' || position == 'fixed') {
          return true;
        }
      }
      if( $(target).filter('*:visible').parents('#modalContent').size()) {
        // allow the event only if target is a visible child node of #modalContent
        return true;
      }
      if ( $('#modalContent')) $('#modalContent').get(0).focus();
      return false;
    };
    $('body').bind( 'focus', modalEventHandler );
    $('body').bind( 'keypress', modalEventHandler );

Since keyboard focus is still on the button that opens the modal (see steps 4 and 5), the keyboard focus target is not within the modal and thus all keypresses except Esc, which is bound to the Close button, are getting discarded.

As a proof of concept, I added

$('.close').focus();

to modal.js just before the lines that bind focus and keypress events to the modalEventHandler function. With this in place, I was able to tab forward through the links on the Add Content modal in the Panels IPE. When I activated one of the links, I was caught in the keyboard trap again.

This trap is an issue on Firefox (Windows, Mac, and Linux) but not on Chrome (W/M/L), Safari (M), or IE 11 (W).

For Safari, Chrome and IE, usability would improve if focus was set to the Close button when the modal opened. Otherwise there are a ton of keystrokes involved.

I tested this patch on Chrome/Mac on a vanilla install of the latest Panopoly dev. It's looking pretty good there. One thing that I found was that it was possible to tab forwards out of the modal settings dialog in some cases, but not backwards.

To reproduce on a clean install of Panopoly with demo content:

1. Log in as an administrator. You should be on the home page.
2. Tab backward (shift+tab) to the Customize this page button and hit Enter to activate it.
3. Tab a bunch of times until you are on the Settings button for the first pane in the Content section. Hit Enter to activate.
4. Note that the red X in the upper right corner is in the hover/focused state (this is right).
5. Tab to the Content Settings radio button group.
6. Arrow up to change the view mode from Featured to Teaser.
7. Tab forward. Note that focus is now in the browser address bar (no longer within the modal).
8. Tab backward a bunch of times. Note that you loop through the modal without escaping.
9. Tab backward to the Content Settings radio button group again.
10. Arrow down to change the view mode back to Featured.
11. Tab forward. Note you are focused on the red X (tab order is not good, but that's a separate issue).
12. Tab forward a bunch of times and note that you loop through the modal.

Firefox/Mac will still need some work. With or without the patch, I can't tab to anything except the navbar menu and the Customize/Save etc. IPE options at the bottom of the page.

I found another tabbing bug where it's possible to tab backwards out of the modal. This is in plain Panels.

Code:

• Core 7.31
• ctools 7.x-1.4+9-dev
• Panels 7.x-3.4+7-dev
• Panelizer 7.x-3.1+84-dev

Modules enabled:

• ctools
• page_manager
• panels
• panels_ipe
• panelizer

Patches:

• https://www.drupal.org/files/issues/ctools-keyboard-trap-2280853-8.patch
• https://www.drupal.org/files/issues/panels-chrome-a11y-2356449-1.patch

Config

• Node view page enabled in Page Manager
• Panelizer configured for the Basic Page content type: full page override, provide default panel, render with IPE, single-column default layout
• One node of type Basic Page created and saved

This is on Mac OS X 10.9.5 with Firefox 32.

Tabbing backward once you've selected a vertical tab will send you out of the modal. To reproduce:

1. On the Basic Page node, tab to and activate the Customize this page button
2. Tab to and activate the Add new pane button
3. Note that the Close Window link is in the focused/hovered state
4. Tab forward to the Comment item in the vertical tabs and hit Enter to activate it
5. Note that the Comment tab is highlighted and the Comment links are in the main area of the modal
6. Note that nothing appears to have keyboard focus
7. Tab backward once
8. Note that nothing appears to have keyboard focus
9. Keep tabbing backward
10. Note that repeated backwards tabs don't appear to do anything - keyboard input is trapped.
11. Tab forward once
12. Note that the Activity vertical tab is now in its focused/hovered state
13. Tab forward or backward as much as you want
14. Note that you are now constrained to tabbing within the modal.

There's also a conflict with Admin Menu/Toolbar Style. To reproduce:

1. Download and enable Admin Menu and Admin Menu Toolbar. Disable core Toolbar.
2. Do steps 1-7 as above (up to tabbing backward after activating the Comment link)
3. Note that the "Hello [username]" link in the Toolbar appears to be focused
4. Continue tabbing backward a few stops
5. Note that you continue to tab through the Toolbar
6. Tab forward the same number of stops
7. Note you have tabbed back to the Close Window link
8. Tab forward and backward as much as you want
9. Note that you are now constrained to tabbing within the modal.

Expected behavior in both cases:
Once you've activated a vertical tab, tabbing backward should focus you on the previous tab. If there are no previous vertical tabs, focus should be on whichever focusable element is before the vertical tabs. In this case, that's the Close Window link.

Related to the above: Once you've activated a vertical tab, when you tab forward once, you always focus on the first vertical tab (Activity in this case).

To reproduce:

1. Do steps 1-6 as in the previous comment (up to where you've activated the Comment link)
2. Tab forward once
3. Note that the Activity vertical tab is now in its focused/hovered state

Expected behavior:
Focus should be on the first link in the Comment section (preferred), or on the next vertical tab. If there are no further vertical tabs, focus should be on the next link after the vertical tabs.

The previous issues also apply to Safari 7.0.6, Firefox 33, and Chrome 38 on Mac OSX 10.9.5, and the same Chrome and Firefox versions on Windows 7.

The problem with tabbing backward doesn't happen on the first load of the ctools modal, but once you've activated a link, it will happen on any state of the modal.

When using IE 11 on Windows 7:

1. On the Basic Page node, tab to and activate the Customize this page button
2. Tab to and activate the Add new pane button
3. Note that the Close Window link is not in the focused/hovered state
4. Tab backward once
5. Note that nothing appears to have keyboard focus
6. Keep tabbing backward
7. Note that repeated backwards tabs don't appear to do anything - keyboard input is trapped
8. Tab forward once
9. Note that the Activity vertical tab is now in its focused/hovered state
10. Tab forward and backward as much as you want
11. Note that you are now constrained to tabbing within the modal.

So for IE 11, the backward tabbing issue happens even on the initial state of the modal.

Also, the issues are different after you've activated a link in the modal. To reproduce:

1. Do steps 1-9 as above (until you've tabbed forward to hit the Activity vertical tab)
2. Tab forward to the Comment vertical tab and hit Enter to activate it
3. Tab forward once
4. Note that nothing appears to be in focus. If you keep an eye on the tooltip that tells you the destination of the focused link, you will see you are on #main-content (the skip link)
5. Keep tabbing forward. Watch the tooltip and see that you are tabbing through the toolbar and the page behind the modal - you can also see the toolbar links get highlighted dimly through the overlay.
6. You will eventually tab back into the modal, but the Close Window link doesn't receive focus the first time you get to where it should be in the tab order
7. Tab forward and backward as much as you want
8. Note that you are now constrained to tabbing within the modal.

However, if you tab backward after activating a link, tab focus moves back to the last focusable element in the modal. To reproduce:

1. Do steps 1-9 in the first sequence (until you've tabbed forward to hit the Activity vertical tab)
2. Tab forward to the Comment vertical tab and hit Enter to activate it
3. Tab backward once
4. Note you are focused on the last link in the modal, which is the Comment Reply Form link

It appears that IE 11 has the opposite problem from FF and Chrome: it handles backward tabbing OK after you've activated a link, but not forward tabbing.

What's probably happening is that when you click a link in the modal, it's changing the state and losing where it should be focused. Focus then tries to go back to the Close button like it does on first load, but something is interfering so it doesn't look or behave like Close is actually focused. Then different browsers interpret where it's actually focused differently, which creates the differing behavior when you tab forward or back.

Very nice. I tested on Mac OSX 10.9.5 with Chrome 39.0.2171.95, Firefox 34.0.5 and Safari 7.1 and have so far been unable to break anything or get myself into a keyboard trap. I added, configured, and deleted panes using the IPE successfully on those three browsers.

However, I ran into these same issues when adding panes using the Page Manager interface instead of the IPE (trapped in Firefox; able to tab out of the modal in Chrome and Safari). Hopefully it's not too hard to add these fixes to the content modals in Page Manager.

Code and patch status for my testing:

Code:

• Core 7.34
• ctools 7.x-1.5
• Panels 7.x-3.4+7-dev
• Panelizer 7.x-3.1+90-dev

Modules enabled:

• ctools
• page_manager
• panels
• panels_ipe
• panelizer

Patches:

• https://www.drupal.org/files/issues/ctool-keyboard-trap-2280853-18.patch
• https://www.drupal.org/files/issues/panels-chrome-a11y-2356449-1.patch
• https://www.drupal.org/files/issues/panels-focus-add-content-tab-2390803...

Config:

• Node view page enabled in Page Manager
• Panelizer configured for the Basic Page content type: full page override, provide default panel, render with IPE, single-column default layout
• One node of type Basic Page created and saved
• One Page Manager page created

How do you specify the dev version of a contrib project on simplytest.me? The patches might only apply correctly using the dev version of Panels.

Or, does simplytest.me attempt to apply all patches to the main project you choose? Since patches are not explicitly associated with the projects you can add, this is probably what's happening. So it doesn't sound like you can apply patches to more than one project, which makes this not a good candidate for simplytest.

Unless you generated the patch(es) from the Drupal site root. Then as long as simplytest puts the modules where you expect them, you could have it patch the whole shebang. That would clutter up the issue queue with patches that were doomed to fail, so they'd have to be uploaded elsewhere.

The latest patch fixes the issue with radio buttons in the modal.

This is looking great in the IPE. Using the Page Manager interface, somehow the fix isn't working. After activating one of the links for a type of content, the symptoms are the same as before the patch. I can't tell if the problem is in this JS or in the fix for #2390803: Keyboard focus should be on the first element in the selected category tab in the "Add content" model (accessibility problem).

Tested on Firefox 35.0.1 on Mac. I've narrowed down the problem to jQuery errors which are interfering with the tab constraints code (this ticket) and the focus on the first element (linked ticket #2390803: Keyboard focus should be on the first element in the selected category tab in the "Add content" model (accessibility problem)). The errors are:

Error: Syntax error, unrecognized expression: tabbable
Error: Syntax error, unrecognized expression: focusable

This is using the standard jQuery version that comes with vanilla Drupal, 1.4.4. I tried updating to jQuery 1.7.1 and got the same errors.

Since the exact same code runs without a hitch when using the IPE, I'm guessing the error is actually somewhere further up the stack?

Here is a stack trace from Firebug:

uncaught exception: Syntax error, unrecognized expression: Syntax error, unrecognized expression: tabbable

k.error()jquery.js?v=1.4.4 (line 85)
g = "Syntax error, unrecognized expression: tabbable"

k.selectors.filter.PSEUDO()jquery.js?v=1.4.4 (line 93)
g = div.ctools-modal-content
i = [":tabbable", "tabbable", undefined, undefined]
n = 0
m = HTMLCollection[div.ctools-modal-content, div.modal-header, a.close #, 21 more...]

k.filter()jquery.js?v=1.4.4 (line 84)
g = ":tabbable"
i = HTMLCollection[div.ctools-modal-content, div.modal-header, a.close #, 21 more...]
n = undefined
m = undefined

k()jquery.js?v=1.4.4 (line 81)
g = "#modalContent :tabbable"
i = div#modalContent
n = Object[]
m = undefined

k()jquery.js?v=1.4.4 (line 102)
m = "#modalContent :tabbable"
p = Document content
q = Object[]
u = undefined

.find()jquery.js?v=1.4.4 (line 105)
a = "#modalContent :tabbable"

c</b.prototype.init()jquery.js?v=1.4.4 (line 26)
j = "#modalContent :tabbable"
s = undefined

$.fn.init()drupal.js?nj4lpj (line 26)
selector = "#modalContent :tabbable"
context = undefined
rootjQuery = undefined

c</b()jquery.js?v=1.4.4 (line 23)
j = "#modalContent :tabbable"
s = undefined

Drupal.CTools.Modal.modalContent/getTabbableElements()modal.js?nj4lpj (line 441)

Drupal.CTools.Modal.modalContent/modalTabTrapHandler()modal.js?nj4lpj (line 495)
evt = Object { originalEvent=Event keydown, type="keydown", timeStamp=1422849539184, more...}

c.event.handle()jquery.js?v=1.4.4 (line 64)
a = Object { originalEvent=Event keydown, type="keydown", timeStamp=1422849539184, more...}

c.event.add/o()jquery.js?v=1.4.4 (line 57)

...{ID:/#((?:[\w\u00c0-\uFFFF\-]|\\.)+)/,CLASS:/\.((?:[\w\u00c0-\uFFFF\-]|\\.)+)/,N...

jquery.js?v=1.4.4 (line 85)

And from the Chrome dev tools:

Uncaught Syntax error, unrecognized expression: Syntax error, unrecognized expression: tabbablejquery.js?v=1.4.4:85 
k.errorjquery.js?v=1.4.4:93 
k.selectors.filter.PSEUDOjquery.js?v=1.4.4:84 
k.filterjquery.js?v=1.4.4:82 
kjquery.js?v=1.4.4:102 
t.querySelectorAll.kjquery.js?v=1.4.4:105 
c.fn.extend.findjquery.js?v=1.4.4:26 
b.fn.b.initdrupal.js?nj4lpj:26 
$.fn.initjquery.js?v=1.4.4:23 
bmodal.js?nj4lpj:441 
Drupal.CTools.Modal.modalContent.getTabbableElementsmodal.js?nj4lpj:495
Drupal.CTools.Modal.modalContent.modalTabTrapHandlerjquery.js?v=1.4.4:64 
c.event.handlejquery.js?v=1.4.4:57 c.event.add.h.handle.o

This may be it: When the core Overlay is disabled, I get the jQuery error. When it's enabled, I don't, and the code works as intended. @dsnopek can you try disabling Overlay on your test site and see what you get? I also updated the referenced ticket #2390803: Keyboard focus should be on the first element in the selected category tab in the "Add content" model (accessibility problem).

I think this is finally it! The only issue with the patch in #31 is that IE 8 does not support the indexOf function on arrays. Using the jQuery $.inArray function is working for me, as tested using IE 11's developer tools set to IE 8 mode. Patch and interdiff are attached.

I have one more problem when using IE/Windows: Focus is not always corralled properly or does not appear where I expect it. Issues are similar between Windows 7/8.1 and IE 8 thru 11. They happen both on the Panelized/IPE node and on the Page Manager page.

Here's what happens using Win7/IE11 on the Panelized/IPE node:

1. Go to the panelized node.
2. Tab to and activate the Customize This Page button.
3. Tab to and activate the Add Content button.
4. The Close Window link is not focused, as I expect it to be.
5. Tab backwards once.
6. Focus is on the Existing Node link (the 2nd to last item in the modal), not on the New custom content link (the last item). (When I tab forward directly after activating the Add Content modal, I end up on Activity, the first item after Close Window.)
7. Tab backwards to Activity and activate the link.
8. Focus is now on the first item in the set (Recent comments), as expected.
9. Tab to Who's Online and activate it.
10. The modal changes to the Configure screen.
11. Tab forward once.
12. I am not constrained to the modal, and I appear to be focused on the Skip to Main Content link on the underlying page.
13. Tab backwards a few times.
14. Eventually focus appears in the modal.
15. Once back in the modal, focus is constrained there. (When I initially tab backward in the Configure modal, I end up on the Cancel button, which is within the modal, and focus stays constrained.)

The functionality is working as expected. Tested on Win7/IE11 plus emulation of IE 8, 9, and 10 using the IE developer tools.

However, the script is now throwing Javascript errors on all browsers/platforms I tested (Mac: Chrome and FF; Windows: IE) in specific circumstances. Here's what happened:

1. Go to the panelized page
2. Tab to and activate the Customize button
3. Tab to and activate the Add Content button
4. Tab to and activate the Node link
5. Tab to and activate Node author
6. Tab to and activate Finish to add the Node author element
7. Tab to and activate the Save button
8. Start tabbing backward through the Change layout and Customize buttons into the rest of the page
9. As soon as I started tabbing through the page content, I got one of these two errors on every tab:

TypeError: lastTabbableElement is undefined
http://dev-a11y.pantheon.berkeley.edu/sites/all/modules/ctools/js/modal.js?njiltt
Line 541
lastTabbableElement.focus();

or

TypeError: firstTabbableElement is undefined
http://dev-a11y.pantheon.berkeley.edu/sites/all/modules/ctools/js/modal.js?njiltt
Line 544
firstTabbableElement.focus();

The errors also occur after any operation that involves saving something in the Add/Configure modal.

I did not see the errors under these conditions:

• Only deleted an item from the page before saving
• Opened the Add Content modal, then closed it without adding and saved
• Opened the Configure modal, then closed it without clicking Finish and saved

Tabbing through the admin toolbar menu did not generate errors. Errors disappeared after reloading the page and did not recur until I did something that involved saving pane settings in the Add/Configure modals.

Looks like maybe the tab trap handler isn't getting unbound like it should? I'll take a shot at fixing this.

OK, maybe this is IT it. The tab trap handler was not getting unbound when the modal closed other than by the explicit Close Window link - i.e., when the modal disappeared after you clicked Finish. In order to allow it to unbind, I had to change the scope of the modalTabTrapHandler by removing 'var'. I also added an explicit unbinding of the Escape handler. New patch and interdiff are attached.