Keyboard accessibility for inline html content

[wojtekpiskorz]

On the demosite we have an example of ligtbox with inline html. This example contains an inner button to close the lightbox. We can use keyboard navigation to jump between arrow and close icon, but we can't access inline html with TAB key. Is there a setting I can't find that would allow for this option?

[wojtekpiskorz]

Here's my code to make the first focusable element focues on lightbox open. It does "kinda" fix it. I can now navigate with tabs through all inner elements of inlineHTML and also through arrow navigation

const lightboxWrapperClassSelector = '.gslide-inner-content'
        const focusableElementsString = `
        ${lightboxWrapperClassSelector} a[href], 
        ${lightboxWrapperClassSelector} area[href],
        ${lightboxWrapperClassSelector} input:not([disabled]), 
        ${lightboxWrapperClassSelector} select:not([disabled]), 
        ${lightboxWrapperClassSelector} textarea:not([disabled]), 
        ${lightboxWrapperClassSelector} button:not([disabled]), 
        ${lightboxWrapperClassSelector} iframe, 
        ${lightboxWrapperClassSelector} object, 
        ${lightboxWrapperClassSelector} embed, 
        ${lightboxWrapperClassSelector} [tabindex="0"], 
        ${lightboxWrapperClassSelector} [contenteditable]
        `;

        var lightboxInlineIframe = GLightbox({
            selector: '.glightbox4'
        });

        lightboxInlineIframe.on('open', () => {
            const lightboxWrapper = document.querySelector(lightboxWrapperClassSelector)
            const focusableElements = lightboxWrapper.querySelectorAll(focusableElementsString);
            focusableElements[0].focus();

        });

[gingerchew]

Thank you for bringing this to our attention!

I hadn't considered this before but you're right, that is a tricky one. If the code you wrote works for you that's great!

Currently though, there is no setting. Adding focusable elements inside of a lightbox/modal's content seems like an anti pattern, but it is still an edge case.

One thing to consider (from an a11y stand point) is how screen readers already interact with the content, and not overriding those controls. Screen readers are much better at "drilling down" than the Tab key is.

The other is that cross browser support is weird. Currently the issue you're running into is partly because of an issue with how Safari handles Tab-ing between controls vs all the other browsers.

So to answer your initial question: No there is not a setting that you are missing, but your patch seems to be working just fine :)