Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dont set aria hidden on large viewports #945

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

koddsson
Copy link

@koddsson koddsson commented Aug 7, 2024

Hello 👋🏻

We're hitting this snag in our app where the sidebar is set with [aria-hidden="true"] when initialized. Apart from being a pretty serious accessibility issue it's also erroring in some cases for us in Chrome with the following in error:

A Chrome error that reads: 'Blocked aria-hidden on a <a> about: srcdoc: 1 element because the element that just received focus must not be hidden from assistive technology users. Avoid using aria-hidden on a focused element or its ancestor. Consider using the inert attribute instead, which will also prevent focus. For more details, see the aria-hidden section of the WAI-ARIA specification at https://w3c.github.io/aria/#aria-hidden. • <a href="#" class="flex items-center p-2 tex t-base font-medium text-gray-900 rounded-lg dark: text-white hover:bg-gray-100 dark:hove
r: bg-gray-700 group"> </a>'

It looks like the sidebar is always initialized as hidden which does make sense in the context of a smaller viewport as it should render hidden and then toggled on and off. It makes less sense on larger viewports where we expect the sidebar to be rendered initially and then optionally users should be able to hide it.

This PR checks to see if we are rendering initially on a small viewport (640px or less) and sets the visibility state accordingly. I also made sure to read the CSS variable --small-viewport so that this size can be changed. I'm not sure if that's the way we'd like to do this. I thought there might be a specific Tailwind variable but didn't find one. We could also read this value from a data attribute if that makes more sense? It would mean that we'd be less likely to clash with a CSS variable set by apps.

Let me know what you think :)

@Lexachoc
Copy link
Contributor

Lexachoc commented Aug 9, 2024

Here is the related issue with reproducible code and videos showing the exact issue.

#943 (comment)
#943 (comment)
#943 (comment)

@zoltanszogyenyi
Copy link
Member

Hey @koddsson,

Thanks for the PR! Why do we set the visible variable to something else other than false?

That sets the visibility to false by default, regardless of smaller or larger devices because the visibility functionality should be the same. From what I understand we have the issue with the aria hidden attribute, so why not add the mobile/desktop device logic only to that?

This could very well break a lot of the base functionality of the drawer, I'll also check it locally in a few days.

Thanks,
Zoltan

@zoltanszogyenyi
Copy link
Member

Also, I think the main issue here is not the usage of aria hidden on larger devices, but rather the possibility to focus or not focus elements within it, so what we should actually do is remove the focus ability for the inside elements when the drawer is actually hidden, both on desktop and mobile devices :)

@koddsson
Copy link
Author

This could very well break a lot of the base functionality of the drawer, I'll also check it locally in a few days.

Any news on this? We've been running this patch in production since I opened this PR and haven't had any problems.

Thanks for the PR! Why do we set the visible variable to something else other than false?

In this PR? I'm setting _visible to match the functionality of the component. When the component is initialized on a small viewport it's initially hidden and can be then toggled on and off.

Large viewport Small viewport
image image

You can see this issue in action on https://flowbite.com/docs/components/sidebar/#default-sidebar.

Screen.Recording.2024-09-30.at.08.59.34.mov

If you look at the HTML of that demo you can see where the sidebar is marked with aria-hidden=true while it's clearly not hidden at all.

Screenshot 2024-09-30 at 09 00 48

@sibeduli
Copy link

sibeduli commented Dec 25, 2024

for those of you using jQuery, i have this quick fix while we wait for this problem to be solved

    $('[data-modal-toggle="popup-modal"]').click(function () {
        var $modal = $('#popup-modal');
        // Check if the modal is currently shown or hidden
        if ($modal.hasClass('hidden')) {
            // Modal is being opened, remove the hidden class
            $modal.removeClass('hidden');
            $modal.attr('aria-hidden', 'false');
        } else {
            // Modal is being closed, add the hidden class
            $modal.addClass('hidden');
            $modal.attr('aria-hidden', 'true');

            // Ensure no element inside the modal retains focus
            $modal.find(':focus').blur();
        }
    });

i'm using flowbite pop-up modal example, so you need to adjust some stuff depending on your needs
i also use MutationObserver for some cases, since flowbite seems to re-add aria-hidden property

    const observer = new MutationObserver((mutations) => {
        mutations.forEach((mutation) => {
            if (mutation.attributeName === 'aria-hidden') {
                const target = mutation.target;
                console.log('aria-hidden detected on:', target);
                $(target).removeAttr('aria-hidden');
                console.log('aria-hidden removed.');
            }
        });
    });

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants