keyboard events inside custom element w/stenciljs

[rramsey]

Hi,

I'm using stenciljs 4.3.x to create a custom html element we can use that will a) be accessible and b) use all of our custom branding and style requirements. I'm using a11y-dialog as a basis for a modal and so far everything is working fine. But when I use a form as the content of the dialog, I can't click or type into any of the form fields. I also can't tab to them. This might be related to #582, but this is a really hard one to isolate. I can't even send you to a codepen or stackblitz to duplicate it because the pieces are too interdependent.

In the parent html, I have:

    <custom-dialog>
        <section slot="content">
            <form>
                <label for="test">test</label><input id="test" name="test" type="text" />
            </form>
        </section>
    </custom-dialog>

Then in the tsx for the custom element I just replace the content of the sample dialog box https://codesandbox.io/s/a11y-dialog-v8-5gqfz8 with <slot name="content"></slot>

I think that what's happening is

1. The a11y-dialog is created,
2. The a11y-dialog js runs,
3. The content is projected into the slot

So when the js runs, it does not know anything about the content, which is why I can't tab though my form or type in it.

Does that make sense as an explanation for what I'm seeing, and if so, any ideas on what I can do to fix it? Is there a good way to delay the a11y-dialog js until after the content is inserted into the dom? Or to re-run it afterwards?

Thanks!

[KittyGiraudel]

Hello Bob,

Thank you for opening an issue, and I’m sorry you’re facing issues using a11y-dialog.

Unfortunately, I am struggling to know where to start with this one without a reproducible test case. What I can say is that a11y-dialog doesn’t do much magic regarding events. This is basically the extent of the behavior:

• When opening the dialog, it binds a focus event listener on the body in order to maintain the focus inside the dialog. This event listener is removed when the dialog is closed.
• When opening the dialog, it binds a keydown event listener on the dialog container in order to close the dialog on ESC and trap the focus on TAB on the last focusable element, or SHIFT + TAB on the first focusable element. In any other circumstances, TAB uses the default browser behavior. This event listener is removed when the dialog is closed.

Could you confirm that using TAB works fine within the content itself? But generally, I would recommend filling the content before opening the dialog, since events are bound on show. Inject your slot content, and then only open. :)

[KittyGiraudel]

I am going to close this for lack for information. Feel free to reopen if you want us to discuss it again. :)