New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keyboard method to jump out of NON-modal dialogs? #599

Open
patrickhlauke opened this Issue Feb 7, 2018 · 6 comments

Comments

5 participants
@patrickhlauke
Member

patrickhlauke commented Feb 7, 2018

In https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal it says

Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.

What are the means for moving keyboard focus outside the dialog window without closing the dialog? Is there a suggested key/key combination (which works reliably for web content)? CTRL+TAB? And if so, can that be expanded on and documented? Also, is it not acceptable to have non-modal dialogs NOT contain focus?

(and incidentally, the only other place "non-modal" is mentioned is in 3.23 Tooltip widget https://www.w3.org/TR/wai-aria-practices-1.1/#tooltip "A hover that contains focusable elements can be made using a non-modal dialog." with no link or reference)

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented Feb 7, 2018

eagle-eyed colleague @IanPouncey just reminded me that the previous ARIA practices did have advice for non-modal dialogs https://www.w3.org/TR/2013/WD-wai-aria-practices-20130307/#dialog_nonmodal and that F6 (keycode: 117) was the suggested key there.

xref #102

@mcking65

This comment has been minimized.

Contributor

mcking65 commented Feb 8, 2018

@patrickhlauke commented:

In https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal it says

Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.

What are the means for moving keyboard focus outside the dialog window without closing the dialog?

  1. Keep in mind that it is not always essential that you can move focus outside without closing the dialog. That will depend on the nature of the content and functionality. Example: a list of notifications and associated functions that overlay the page but do not render the lower layer inert. The ability to keep it open while working elsewhere may not be a valuable feature in all circumstances.
  2. If moving focus outside the dialog without closing is valuable, there should be visible elements in the dialog that provide such functionality. For example, say a rich text editor shows a list of comments and revisions in a dialog. Activating a comment could move focus to the comment indicator in the document. Activating an element on a popup menu for the indicator could place the focus back in the dialog on the comment.
  3. Hotkeys could also be defined. They may be associated with specific elements that are inside the dialog, on a toolbar outside the dialog, etc.

Is there a suggested key/key combination (which works reliably for web content)? CTRL+TAB? And if so, can that be expanded on and documented?

We will definitely document recommendations when we complete issue #59. F6 has been suggested in the past, It is intuitive on some platforms, but comes with implementation complexity given how the browsers use it. The same is true of ctrl+tab. This promises to be a thorny issue where we will have to thread a needle.

Also, is it not acceptable to have non-modal dialogs NOT contain focus?

If a container does not contain the tab ring, then it would be missing a key behavior of a dialog.
There are a wide variety of structural containers that could be used instead.
For example, a sidebar panel could be marked up as a region, even if that region is collapsable and moveable.
In that case, the disclosure pattern could be used.
The disclosure button could control a landmark region.
The region could contain an an actions menu that renders the functions for moving and sizing.

(and incidentally, the only other place "non-modal" is mentioned is in 3.23 Tooltip widget https://www.w3.org/TR/wai-aria-practices-1.1/#tooltip "A hover that contains focusable elements can be made using a non-modal dialog." with no link or reference)

Right, I had to remove the reference because we didn't complete issue #59. And, we removed the previous content and raised issue #59 because we haven't yet worked on bringing that old content up to the editorial standards and getting consensus on what should be in the pattern.

@mcking65 mcking65 added this to Next Steps in Dialog Patterns and Examples Development Project via automation Feb 8, 2018

@mcking65 mcking65 added this to the 1.1 APG Release 2 milestone Feb 8, 2018

@patrickhlauke

This comment has been minimized.

Member

patrickhlauke commented Feb 8, 2018

Thanks for the response Matt. All good points that I look forward to seeing in the documentation :)

Regarding complexity of F6 (and CTRL + TAB) is the concern mainly about hijacking native browser functionality via preventDefault()ing?

@jnurthen

This comment has been minimized.

Contributor

jnurthen commented Apr 10, 2018

@DuongTrongNguyen

This comment has been minimized.

DuongTrongNguyen commented Oct 1, 2018

?

@carmacleod

This comment has been minimized.

Contributor

carmacleod commented Oct 2, 2018

@patrickhlauke

Regarding complexity of F6 (and CTRL + TAB) is the concern mainly about hijacking native browser functionality via preventDefault()ing?

Probably. :)
My 2c:

  • I think hijacking CTRL + TAB from the browsers would be a problem and should be avoided.
  • Regarding F6, however, I think of it as an "outer focus ring", separate from the TAB focus ring. It would be interesting to try handling F6 without preventing the default behavior. More thoughts on this below...

In old Windows desktop apps, F6 (SHIFT+F6) would navigate through "panels", including any open non-modals. Some apps still use it. You can see it in the Windows File Explorer (although behavior there now is not that different from TAB any more).

In Firefox (Windows and Mac) F6 navigates through the address bar, bookmark/history sidebar (if open), and document. (I believe it also [used to?] navigate through <frame> elements in the document, if any).

In Chrome (Windows only) F6 navigates through the address bar, bookmarks bar, document, and DevTools Console (if open).

I think of these areas as "landmark-like". I think it would be useful to have F6 (and SHIFT+F6) navigate through ARIA landmarks, non-modal dialogs, and the browser's address bar and other bars/sidebars, etc. (modal dialogs would be navigable also, but only between the modal and the browser areas).

If you use Slack, you can try out a nice implementation of landmark navigation using F6 (SHIFT+F6) in their desktop app. (They don't appear to have any non-modal dialogs, but if they did, I wouldn't consider it a stretch to add them to the "F6/outer focus ring" navigation).

When inside a web browser, Slack uses CTRL+F6 (CTRL+SHIFT+F6) for landmark navigation. Presumably they didn't want to hijack the browser's F6 (SHIFT+F6), or perhaps they tried merging their navigation with the browser's and decided that it was too problematic - I don't know. (I'm wondering if the user needs to type an extra F6 to keep moving forward after the browser focuses the document).

Sure would be nice if the browsers would implement this, instead of everybody having to roll their own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment