Polaris-react: [a11y][Modal] Manage focus to first focusable element when available

Created on 5 Sep 2018  路  7Comments  路  Source: Shopify/polaris-react

Issue

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:

  • Users must tab to or click into the first field or control to start interacting. Products that use Polaris often have modals that contain only a form, or even a single form field, so this extra interaction slows users down.
  • Sighted keyboard-only users may not be 100% sure that focus is in the modal since it isn't visible on the modal container.

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.

Recommendation

Dynamically manage focus based on the content of the modal.

  • If the first element in a modal's main content (Polaris-Modal__BodyWrapper) is natively focusable, send focus to it. (This will almost always be a form field.)
  • If the first element in a modal's main content is natively non-focusable content (text), fall back to our current standard of sending focus to the modal container.
Accessibility 馃 Finalize exploration

All 7 comments

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!

Was this page helpful?
0 / 5 - 0 ratings