When the Modal component opens, focus goes to the modal container by default. This is the most content-agnostic focus management approach, and it works great for modals that have primarily text-based content. However, the experience for modals that primarily contain form fields or other interactive controls could be improved. Currently:
See https://github.com/Shopify/polaris-ux/issues/193 for additional discussion.
See the ARIA 1.1 authoring practices for modals, which recommends a more targeted focus approach.
Dynamically manage focus based on the content of the modal.
Polaris-Modal__BodyWrapper) is natively focusable, send focus to it. (This will almost always be a form field.)The situation this could break is if the modal had a text field but it wasn't the first element (e.g. there's a banner above it). Could we simply disable the focus on the modal if there is a natively focusable element there?
If there鈥檚 a banner in the modal, should it not get focus? Even if I鈥檓 not using a screen reader, I would expect to be able to tab through the interactive elements in the modal in the order they appear on screen.
It makes sense for accessibility to focus on the first element even if it's a banner, but needing to tab or click to focus the input can slow down common workflows. This may be a trade-off we'd have to make though. Just thinking if there're any edge cases where focusing the first element may not be what we want.
My feeling is that a banner in a modal should be uncommon. When there is one, I鈥檇 want it to be the first thing in the tab order and to receive focus first.
Because it shouldn鈥檛 be common, you鈥檇 still get the speed boost for most modals with forms. I鈥檒l defer to @dpersing though.
When there is one, I鈥檇 want it to be the first thing in the tab order and to receive focus first.
Agreed. The Polaris banners are technically focusable (in that they they have a tabindex="0" on them and show a focus indicator). If there is a banner for some reason at the top of the modal content, I'd recommend it get focus first since it's presumably providing some context or condition. If focus skips the banner and goes to a field instead, non-visual users will likely miss that context.
Just giving an extra 馃憤 on this, using the new modal in web's resource picker seems to be the source of a break in the (albeit terrible) UX flow of typing into the resource picker activator (a text field) and continuing to update the value while typing in the picker's search field after the picker opens 馃槪.
Just reviewed the proposal here in light of https://github.com/Shopify/polaris-ux/issues/237, and I think it鈥檚 a great complement to that issue. If we do this proposal, and give modals (and popovers) a visible focus state when interacted with via the keyboard, we鈥檒l be in good shape!