Can we avoid hijacking tab?

[davidtheclark]

Right now this library hijacks Tab. It relies on tabbable to determine the tabbable nodes within the focus-trap, and their order, then moves focus accordingly when you hit Tab, instead of letting the browser do its default thing.

There are a couple of issues with this approach:

• tabbable does not (and probably cannot) perfectly match the browser's default behavior. The main symptoms of this are that tabbable is not going to pick up on iframes or shadow DOM — so in a focus-trap those elements won't receive focus; and it also can't handle radio sets.
• It seems unfortunate: it would be nice if we didn't have to hijack default browser behavior but could somehow just rein it in a little.

If we could find an approach that fixes those issues and still works in all the ways focus-trap currently works — that would be great. I'm opening this issue to hear any ideas anyone has for solving this problem. Input welcome!

---

I tried experimenting a bit with an alternative approach today. I used tabbable only to grab the first and last tabbable nodes in the trap. Instead of listening to Tab events, I listened to focusout events: if event.relatedTarget comes before the previously focused node (so you're shift+tabbing), I'd focus the last tabbable node; if event.relatedTarget comes after, I'd focus the first tabbable node. I ran into 2 bad roadblocks:

• This seemed promising on a few of the demos, but then crashed and burned with demo 3. When tabindex is deliberately set anywhere on the page it messes up the whole approach.
  • Maybe this problem could be accepted as a caveat and we could recommend strongly against the use of tabindex 1+ (which some accessibility experts also strongly discourage Paciello Group, WAI-ARIA Practices, Google Web Fundamentals).
• The first and last focusable items in the trap still need to be recognizable to tabbable.

[davidtheclark]

Closed by #59.