accessibility for non-modal windows in UI

Question

In our application, we have a case, where a page can have multiple non-modal popups. And I am working on making those popups keyboard accessible.

Without any accessibility addition: popups and focus-able elements inside are still accessible. If 5 popups open, first tabbing cycle goes through all elements on page itself and next cycle from page top, goes through pop-ups. Not nice but still accessible.

With few changes: So We decided to have popups focused when trigger/parent is clicked.This worked to some extent and created whole new set of problems.

Now parent clicked, popup opens and gets default focus and can tab into it. Similarly we can have many popups opened. Focus stays trapped inside popup and F6 is pressed to bring focus out and it goes to page top.

Problem with new changes: When on F6, focus again starts from page top and cycles through page elements and enters first opened popup.

1#: Should no enter popup on its own. Like some key press on parent (eg F6). But having tabindex on elements let it do that and can not change tabindex values.

2#: Focus enters first popup and trapped inside. F6 pressed ,it goes on page top and with tabbing, reaches back to first popup again. It never gets chance to enter other popups and keeps cycling between first popup and all other page elements. So having issue#1 fixed looks important to me.

3# Closing non-modal popup with KB should focus back to parent element which is not possible in my design.

Any accessibility experts here can suggest me true non-modal behavior.

Answer 1

It is definitely something that needs to be thought through holistically.

You can have different layers of keyboard control, for example, the tab key and the arrow keys, but their use can vary depending on what has the current focus.

One approach could be to use the arrow keys to cycle between the non-modal pop-ups, and use the tab key to cycle through the contents of the non-modal pop-up. As each non-modal receives focus you should ensure it is visually highlighted in some way. ARIA landmark attributes can also be used to identify each non-modal pop-up, which will definitely help blind users who use screen readers because most screen readers have a keystroke to list the landmarks and from this list they can navigate to each landmark.

You can also put major UI elements into the arrow key cycle, e.g. tab groups. Once the tab group has the focus the arrow keys can now be used to move to each tab. When the tab has the focus the tab key can now be used to going through the contents of the tab.

The Yahoo developer Network has some good advice on this too: https://developer.yahoo.com/blogs/ydn/keyboard-accessibility-applications-53729.html

Answer 2

This sounds similar to some intranet tools I've worked on in the past. You may have some different use cases however so I'm interested to see how this works out in your situation.

The biggest suggestion I would offer is Control + Tab key combination. While not all users may be used to this, many applications support it and for good reason. Just like tabbing does for elements within a pane, the control button should be viewed as promoting it to a super-tab.

Right now, you are tabbing through the entire tab-index of all windows, correct? You can save the index of the first element in each child window into a list/vector/array attached to the parent window. You'll have more interface flexibility if you can store these 'tab offsets' in a parent->children[] node tree.

When someone uses control-tab, advance the 'current child index' and reset the tab index to it's specific offset (the tab index of it's first element). When someone uses normal tab, have it cycle inside the window it's in, resetting to 0 if it reaches a tab outside of that. You may be able to eventually setup child-local tab-indexes this way as well so you don't have to track it as much.

ANYWAY, with that in mind, you can also display the list of any parent's child windows attached to the border of the parent, visual tabs. When clicked, you'll zoom to the window you wanted. Alternatively this could be a toolbar of sorts free floating. There have been times we allowed users to drag/drop a visual tab onto a toolbar to make 'shortcuts' to windows (they had a lot going on with charts as well) but that get's into non-keyboard situations.

Finally you should keep some sort of left-right ordering between different levels along with a history of previous tab. What this does is allows users to switch between the parent levels when the parent has focus and child levels if the child has focus. You can make the parent gain focus after the final tab, before reseting the child index back to zero. This also enables the use of shift tab to back up in the same order your user just went which opens up more organization and task switching capabilities for the user.