Overlay tab order ends in endless loop [#2121931]

Problem/Motivation

The tab order of items inside the Overlay can result in an endless loop. This can cause keyboard-only users to get stuck in that loop, unable to return to the Overlay. Unable to click Save, their work is lost.

The tab order seems to go bad after the Save or Preview button at the bottom of an overlay form. Tabbing past that point puts the focus on the browser tools. At that point if you tab back (Shift-Tab), it will not go back into the Overlay. If you tab forward, you will cycle through all the browser tools but never be able to tab back to anything on the page.

If you turn off Overlay, the tab order on these forms works fine. You can get through the form, past the end, and tab back into the form. You never get stuck in the loop with overlay off.

This behavior was reproduced in Safari 6.1 on Mac and in Chrome on Windows. A screenshot is attached illustrating the tab order.

Screen Shot illustrating tab order problem

Proposed resolution

Troubleshoot why the browser gets stuck in this loop when overlay is on. Fix tab order or fix browser compatibility with different markup.

Perhaps this solution would be fixed with some of the fancy new tab order management tools, a la #1874664: Introduce toolbar level "Edit" mode that shows all contextual links.

As an alternative, a solution could be disabling overlay or making it easier to disable or get out of. That would act as a work-around to alleviate this problem for keyboard-only users.

Remaining tasks

Troubleshoot and recommend appropriate HTML or JS to address this.
Write patch and tests.

User interface changes

The goal is to make efforts to improve accessibility easier, so keyboard navigating users will have a better experience with Drupal.

API changes

None proposed.

Comment	File	Size	Author
	Screen Shot 2013-10-27 at 10.18.56 PM.png	224.47 KB	bowersox

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

bowersox CreditAttribution: bowersox commented 28 October 2013 at 03:43

FYI, this issue was reported at the Minnesota accessibility testing sessions, where the users reported it as follows:

"When creating a new article using only the keyboard, if the participant tabs past the end of the article editing area he cannot tab back into it. This is most likely because the editing window appears to be set up as a modal window without all of the necessary accessibility implementations. This behavior is actually seen on many types of editing pages, like editing his profile. The participant was on Firefox on Windows and Mac."

We've reproduced it at this URL /node#overlay=node/add/article , but based on the report it is likely a problem with all overlay forms.