Studio: Solve accessibility warning on user settings

[katinthehatsite]

Related issues

Fixes: STU-504

Proposed Changes

When the Popover (dropdown menu) for Delete all preview sites is closed/hidden, it has aria-hidden="true" (set by WordPress components) applied to prevent screen readers from accessing its contents. However, the MenuItem still has focusable attributes (aria-disabled) even when hidden. I believe this creates a conflict because an element marked as aria-hidden="true" should not contain any focusable descendants.

Solution:
I propose to use the DropdownMenu's isOpen state to only apply focusable attributes when the menu is visible, and remove them when it's hidden. This ensures there are no focusable elements inside the Popover when it's hidden with aria-hidden="true".

This maintains proper accessibility by:

• Allowing focus and state announcements when the menu is open
• Properly hiding all content from screen readers when the menu is close

Sidenote: Another solution that I tried as to render the menu in the root and outside of the DOM structure by using __unstableSlotName: 'root' prop but I don't think it is a good solution to do this. Happy to discuss other alternatives as well.

Testing Instructions

• Pull the changes from this branch
• Start the app with npm start
• Make sure that you have no preview sites
• Open the developer tools
• Navigate to User Settings in the top right corner
• Open the Usage tab
• Confirm click on the three dots to by Preview sites
• Observe that when the focus goes on Delete all preview sites, there is no warning in the dev tools
• Try switching between different tabs and site and triggering the User Settings a couple of times to confirm it works (as in the issue originally, it is not something that I could always reproduce consistently)

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[epeicher]

Thanks for working on this!

I have tested this and I have received the warning, I have double checked I was in this branch. Then I have moved to trunk, trying again and not getting the warning, then moved again to this branch and not getting the warning anymore 🤷 .

Sorry for not being very helpful 🙏 , but as mentioned in the issue, it seems that is not very consistent. Let me know if I can help more with this 😄

This is a screenshot of the first time I tried in this branch

[katinthehatsite]

Let me take a look 🫠 Thanks for checking!

[katinthehatsite]

@epeicher I discovered that the issue is a bit bigger than this so I am going to close this for now I open a different PR.

[ivan-ottinger]

Just by coincidence, I noticed the issue while going through smoke-testing today, but similarly as Roberto pointed out, it does not get triggered consistently. 🫤

Curious to see where exactly it is coming from.

[katinthehatsite]

@ivan-ottinger It comes from the wordpress/components Modal. I explained a bit more in #1423 and proposed a different fix. It also affects multiple places not just User settings