3

I have a button that shows a non-modal dialog, like this:

Symbol picker mockup

The "Show Symbol Picker" button brings up the symbol picker non-modal dialog. If the button is pressed again, the dialog stays open, and brings it to the front if it's behind other non-modal dialogs.

The button is able to be focused by using the Tab key. If the user presses the Enter key while it is focused, the non-modal symbol picker appears as described above.

However, I am unsure of where focus should be after the user presses the Enter key. Should it be on the dialog or the button? What if the modal dialog is already open and the button is pressed again (an action that normall brings the open dialog to the front)?

I would like to find an authoritative source on keyboard accessibility. Also, I'm not looking for an alternative design that eliminates the button or non-modal dialog (it's a business requirement in an existing design, which I don't have the power to change at this time).

Improve this question

2 Answers 2

Reset to default
1

Need more context here. Behaviour is different for desktop (windows, mac) app as compared to web.

Desktop

The dialog opens as a new window. Typically, the new window gets focus. User can tab to return focus to the main window, while keeping the smaller dialog. Or close the window using the close window shortcut (Windows: Ctrl + W , Mac: Cmd + W)

Web

Web behaviour is a bit more varied, but using the "Esc" key to dismiss a dialog is common enough. As usual, if a user choose to perform an action that brings up a new dialog, the assumption would be they want to interact with elements on the new dialog. So place focus on the first button of the dialog. Tab will go through all buttons on dialog. The "X" to dismiss dialog should also be tab-able. User can "Shift + Tab" to access the "X" or tab through all the buttons to return back to the "X" or hit "Esc" to directly dismiss the modal.

Update From comments, OP indicated users would actually benefit from being able to view the symbols in the main window. Therefore, we should consider treating the dialog as a side pane directly shown on the screen. Or a "group" as defined by WAI_ARIA http://www.w3.org/TR/2013/WD-wai-aria-practices-20130307/#kbd_layout_whatgroup Perhaps tie the group to the "Show Symbol Picker" button. If it's open, put the 1st button in focus, but allow users to shift tab to return back to the Show Picker button or if user is at the end of the button list, tab will put focus onto the next element after the Show Picker button on the main screen.

Improve this answer
7
  • 1
    It's web, but I appreciate you providing information for both. However, I'm a bit confused about your web example. Are you saying that the user cannot tab to return focus to the main window, as you can on desktop? Also, do you have any sources to back this up?
    – Thunderforge
    Oct 2, 2015 at 18:25
  • 2
    A dialog that is not in a model is a bit rare on the web. Honestly I've never seen floating dialogs on web that's functions using keyboard controls only. The standard reference for access control is W3C's WAI-ARIA guidelines. They mention keyboard access to elements outside the modal may be disorientating. There's no mention of non-modal style dialogs. w3.org/TR/2013/WD-wai-aria-practices-20130307/#modal_dialog
    – nightning
    Oct 2, 2015 at 18:54
  • 2
    A question you should ask is, what does the user gain by being able to keyboard navigate to the main content with the modal still shown? Keyboard controls only allow you to move one element at a time down the list. It may be quicker to close the modal, do your action and reopen the modal as oppose to tabbing through all the modal actions before returning to the main screen.
    – nightning
    Oct 2, 2015 at 18:54
  • 1
    I believe the thought behind this was that sometimes users will want to be able to see what is available in a non-modal dialog while interacting with elements on the main page. For the symbol picker, that would mean being reminded that there are certain characters available. Perhaps we could express this through some way besides a non-modal dialog, but that isn't an option at this time.
    – Thunderforge
    Oct 2, 2015 at 19:01
  • 2
    I see. Then consider treating the dialog as a side pane directly shown on the screen. Or a "group" as defined by WAI_ARIA w3.org/TR/2013/WD-wai-aria-practices-20130307/… Perhaps tie the group to the "Show Symbol Picker" button. If it's open, put the 1st button in focus, but allow users to shift tab to return back to the Show Picker button or if user is at the end of the button list, tab will put focus onto the next element after the Show Picker button on the main screen.
    – nightning
    Oct 2, 2015 at 19:11
0

Dynamicly added/new content:

If you're arguing that this is not a "modal dialog", but instead content created by a trigger element (link or button), then WCAG has a slightly different guide on how to handle the new content.

See this WCAG resource on implementation of "Inserting dynamic content into the Document Object Model immediately following its trigger element"

The reading order in a screen-reader is based on the order of the HTML or XHTML elements in the Document Object Model, as is the default tab order. This technique inserts new content into the DOM immediately following the element that was activated to trigger the script. The triggering element must be a link or a button, and the script must be called from its onclick event. These elements are natively focusable, and their onclick event is device independent. Focus remains on the activated element and the new content, inserted after it, becomes the next thing in both the tab order and screen-reader reading order.

Seems to imply, under the "description" section, that to be WCAG compliant, all you need to do is insert the new DOM immediately following the DOM for the triggering button. This applies more generally to what you are trying to accomplish, and seems to satisfy your business requirements. It even provides information on the tab order and current focus following your immediate click.

Dialogs:

Clicking the button adds content to the screen. Focus needs to be shifted to the new content, or screen reading users will be lost. Until the dialog has been closed, the user should not be able to tab outside of the dialog.

See this WCAG resource on dialogs

New HTML content like dialogs should be inserted into the DOM directly after the element that activated it. Focus should be sent to and trapped inside the new dialog. The ESC key should close the dialog. Make sure the X (close) button is keyboard accessible and has a text alternative. When the dialog closes, focus should return to the element that activated it.

I was lead to this resource by a Wiki that is managed by the WCAG working group. The wiki/source can be found here: http://www.w3.org/WAI/GL/wiki/Managing_focus_for_modal_dialogs

There are additional resources available, and some instructions/guides around implementation. If your application isn't a web application, many of the takeaways still apply.

Improve this answer
9
  • 1
    This situation is about a non-modal dialog, not a modal dialog. A user can leave the window with a mouse. If they can't leave by tabbing, wouldn't that mean it's non-modal for mouse users and modal for keyboard users? That's not what we want.
    – Thunderforge
    Oct 2, 2015 at 17:48
  • 1
    At the very least, it is new content that has appeared on the screen as a result of user action. The user's focus should be on the new content, or else screen readers will not know that new content exists (or the result of their action). Trapping the user in the dialog is up for debate, but I see no harm in trapping them in the dialog until it has been closed (even if the UX is different for users with access to a mouse).
    – Daniel Brown
    Oct 2, 2015 at 17:59
  • 1
    So assuming that the user was permitted to leave the dialog, what is the proper behavior if the user goes back to the button that opens up the dialog. Focus goes back to the dialog as it did when it was first opened?
    – Thunderforge
    Oct 2, 2015 at 18:00
  • 1
    Hmm.. I would argue that clicking outside of the dialog, or tabbing outside of the dialog, should close the dialog (if that's your desired behavior). However, it may be preferable to lock them to the dialog so their tabs continue to circle the options until a choice is made.
    – Daniel Brown
    Oct 2, 2015 at 18:05
  • 1
    I think there's a misunderstanding. The user is allowed to get out of the dialog and tab-navigate to other elements. No locking them in, and no closing the dialog if they click outside or close it. This is a business requirement we cannot change (besides, I think there are a lot of valid use cases where it can happen). I'm interested to know where focus shoudl go if the user tabs back to the initial open button and activates it.
    – Thunderforge
    Oct 2, 2015 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.