Design general focus trapping solution

[hansl]

We need a way to trap the focus inside a piece of DOM (or outside a piece of DOM), wrapping or refusing to tab in/out.

This includes the task of writing utility functions for detecting focusable elements.

[jelbourn]

@marcysutton do you have an input on a general focus-trapping utility?

One question I have is whether trapped focus should wrap (forward and backward) in the trapped region, or whether it should just stick to the beginning / end.

[hansl]

That should be a type of trapping.

What I had in mind was something akin to:

<div md-focus-trap="wrap">
  <!-- ... -->
</div>

or

<div md-focus-trap="nowrap">
  <!-- ... -->
</div>

Whether the default would be one or the other doesn't matter much. WDYT?

[marcysutton]

Providing options is nice in an API, however I don't think it's appropriate in this case. The convention is to wrap focus in modal dialogs, and it's what a keyboard or screen reader user would expect. It's also a WAI-ARIA best practice. https://www.w3.org/TR/wai-aria-practices/#modal_dialog

A better question is whether to trap focus inside of the dialog, or allow it to get to the browser chrome. I have heard users say they prefer it to truly be trapped in the dialog (no browser controls).

Here is part of an implementation by @rodneyrehm you can reference: https://github.com/medialize/ally.js/blob/master/src/maintain/tab-focus.js

[marcysutton]

Unless you're envisioning a keyboard trap for some other purpose than a dialog? I am curious to hear....I still think stopping a keyboard user at the end of an arbitrary tab sequence sounds like a bad idea.

[rodneyrehm]

We need a way to trap the focus inside a piece of DOM (or outside a piece of DOM), wrapping or refusing to tab in/out.

Do you need to trap / prevent focus for Tab and Shift Tab only, does this also apply to mouse, touch and other means of shifting focus (e.g. spatial navigation)?

Instead of trapping focus by intercepting user input, you want to simply disable all the elements that should not receive focus at a given time. ally.maintain.disabled can help with that.

This includes the task of writing utility functions for detecting focusable elements.

I've done the research on what is focusable (1.5MB) and turned that into code (e.g. ally.query.focusable, MIT licensed).

One question I have is whether trapped focus should wrap (forward and backward) in the trapped region, or whether it should just stick to the beginning / end.

Most dialog implementations I've come across wrap the focus from last to first and vice versa. But most of the implementations I've seen consider the tabsequence to equal DOM order. However, the tabindex attribute, Flexbox order property in Firefox, Image Maps and Shadow DOM do not agree with that assumption. With ally.query.tabsequence you have a simple query interface accounting for these things.

[hansl]

Aside from Dialog, I think focus trapping is also done in some menus and most dropdowns.

[jelbourn]

@hansl we may want to bump this to alpha.2