Disable ariaHideOutside with comboBox?

[heisand]

Is it possible to somehow disable the ariaHideOutside functionality using the comboBox? Sometimes it is not always necessary to hide the other content, e.g., if you want to simply close the listBox on blur.

[LFDanLu]

Is it possible to somehow disable the ariaHideOutside functionality using the comboBox

Not at the moment, and we most likely won't make that configurable since it helps limit the scope of elements available to a screen reader user to the ones relevant to the operation of the combobox while open.

Sometimes it is not always necessary to hide the other content, e.g., if you want to simply close the listBox on blur.

Mind expanding on this? Is there an element outside the ComboBox that ariaHideOutside is blocking you from? For a keyboard user hitting Tab should still allow you to blur from the ComboBox and mobile screen reader users can dismiss the popover/tray to unhide the elements outside of the combobox.

[heisand]

I am thinking about using screen readers. When navigating with that you then have to use the dismiss button to unhide elements and navigate further. Sometimes it feels smoother to just be able to navigate further and then let the listBox simply close when another element is focused.

An example of that is on https://ruter.no/en/ (a Norwegian transport company), where that is the case.

I have asked the authority for universal design of ICT in my country about what they believe is the best approach, waiting for an answer. I was just curious whether you had made any thougths about this.

[LFDanLu]

When navigating with that you then have to use the dismiss button to unhide elements and navigate further. Sometimes it feels smoother to just be able to navigate further and then let the listBox simply close when another element is focused.

Definitely a valid point, but in our case we use React Portals to move the Popover to the end of the document for rendering reasons, meaning that a mobile screenreader user wouldn't land on the Popover when swiping past the ComboBox's input, instead landing on whatever element is adjacent to the combobox input, thus losing the ComboBox's informational "context". This blog post goes into the above in more depth.

IMO it doesn't feel that much more awkward to force the screen reader user to close the Popover via the dismiss button. We have a dismiss button at the top and bottom of the Popover/Tray so that a user can more easily close the popover if they decide not to select any of the available options, otherwise they can simply select an option to close the Popover. Without the ariaHideOutside, a user still would be swiping into and through the Popover to get to the next element after the combobox anyways, so the dismiss buttons are just a couple of extra elements.

Happy to discuss though, perhaps we could consider allowing users to disable the ariaHideOutside behavior if they aren't portalling the dropdown menu, especially if the behavior of hiding other elements outside the popover when it is open feels odd to mobile screen reader users.

[heisand]

Yes, I noticed it is placed at the end of the document, but I looked into not doing that in my case 👍 Maybe I then can open a feature request at some point and it could be discussed further. I can wait for an answer from the authority for universal design, to perhaps have more input on the case.

[mmorris8]

I'm using the native Popover API and am now getting errors from the component. One of the reasons for using the Popover API is this logic is natively handled by the browser. I'd like to disable it as well. Either that Or put it into my native popover.