Fast: bug: Fast button component not added to tab queue in fast dialog by default

[scomea]

Fast button elements that are children of a fast dialog don't appear in the dialog's tab queue because fast buttons are not detected as tabbable because the button tag is not discovered because it exists in the shadow dom.

A possible solution is to mark fast-button elements with a tabindex of "0" by default so tabbable discovers it. This may affect other web components that hide focusable elements in the shadow DOM and aren't marked wiht a positive tab index.

Example:

1. Create a modal fast dialog with several fast-button children
2. Try to tab between them, note that it doesn't work
3. Add tabindex="0" attributes to the buttons
4. Try tabbing between them, note that it does work

Fast buttons should show up in dialog tab queues by default.

[scomea]

Related issue to be aware of - https://github.com/microsoft/fast/pull/4036

[SethDonohue]

For now are we sticking with the author needing to add a non-negative tabindex to the fast-buttons for it to show in the dialog tab queue, or are we thinking of changing fast-button to have a tabindex="0" by default? Just curious if there has been any movement on this.

[chrisdholt]

For now are we sticking with the author needing to add a non-negative tabindex to the fast-buttons for it to show in the dialog tab queue, or are we thinking of changing fast-button to have a tabindex="0" by default? Just curious if there has been any movement on this.

I think when @EisenbergEffect lands the Provider DSL we'll be able to plug into that and leverage some of the benefits for our own trap focus implementation. The problem here is that we need to maintain a list of all HTML focusable elements as well as a list of our focusable custom elements, while also providing a method for users to register their own. Add to this the fact that someone may register our custom elements with a namespace other than "fast". I think the provider DSL will provide a hook for us to handle all of that fairly elegantly. For now, because that's not landed, we'll keep the code as is using tabbable, which requires tabindex="0" for custom elements.

[m4thieulavoie]

@chrisdholt are you suggesting people manually add tabindex="0" in their own app for now, or that FAST handles that internally (by adding tabindex="0" if none was specified by the user)? If the latter, I'm happy to contribute if you want 👍

[SethDonohue]

For now, we need to add tabindex="0" manually. The work he mentioned above with the Provider DSL will help with this issue once it is ready.

[chrisdholt]

@chrisdholt are you suggesting people manually add tabindex="0" in their own app for now, or that FAST handles that internally (by adding tabindex="0" if none was specified by the user)? If the latter, I'm happy to contribute if you want 👍

@m4thieulavoie yeah, for added clarity on what @SethDonohue mentioned, there are a few considerations that make this difficult to handle all up currently. Currently we use tabbable which doesn't have a method for accounting for custom elements. We need to create a utility for trapping focus and while we could likely handle anything with a fast prefix today, the problem really starts in foundation prior to things being registered.

The DSL work will ultimately provide an avenue for us to account for any registered instance of "button" for example. Without that, we can account for elements such as fast-button, but what happens if I register as fluent-button or baz-button - we need to account for the larger story there. The other bit that we need to account for is custom elements which are focusable that aren't part of our package; the registration will be helpful here as well since we can provide a method for folks to opt in.

I'll see if I can work up a task tracking the creation of the trap focus utility with requirements and link that here.

Currently tabbable provides a (less than ideal for us) method of bringing focus. Hopefully the Provider updates will be in soon and we can get rolling on a more elegant update here!