Enforce datepicker overlay modality in ATs

[rolfsmeds]

What is the problem?

From 2022 TetraLogical a11y review:

It is possible to access content outside of the calendar modal dialog with a screen reader running. Ensure that all content outside of the dialog is hidden in the accessibility tree. This can be done by applying aria-hidden="true" to the containers of all items outside of the dialog, but not the parent of the dialog (for this reason it's recommended that the dialog is a child of the

element). Alternatively, you can use the inert attribute in the same way as the aria-hidden attribute, which also removes focusable elements from the keyboard tab order, but you will need to use a polyfill (such as https://github.com/WICG/inert) for most browsers. See https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal for more information.

Not sure what the best solution would be here:

• In Flow apps we could apply aria-hidden or inert to the rest of the UI (for overlays in general), as we are in control of the whole DOM structure and know where the "inline" parts of the UI are, but this would need to be a Flow feature and would not help with non-Flow usage of the component. (Perhaps we could simply document applying it manually whenever an overlay opens?)
• Implementing focus trapping in the datepicker overlay would prevent focusing elements outside the overlay, but I'm not sure it would affect virtual cursor navigation (whereas e.g. inert would).

Browsers

• [ ] Chrome
• [ ] Firefox
• [ ] Safari
• [ ] Safari on iOS
• [ ] Edge

Screen Readers

• [ ] None
• [ ] NVDA
• [ ] JAWS
• [ ] VoiceOver on MacOS
• [ ] VoiceOver on iOS

[web-padawan]

We should have a common solution that would also apply to modal vaadin-dialog and vaadin-app-layout drawer. One option would be to try @react-aria/aria-modal-polyfill that is based on aria-hidden package.

[yuriy-fix]

Let's research the solution for 2 days. And 2 days for implementation for date-picker + dialog + app-layout drawer.