Provide context to modal setFocus method where focus is set on the close button

[nwhittaker]

Actual Behavior

When opening a modal with disable-close-button disabled, the close button now always gains the initial focus.

If disable-close-button is enabled, the content slot is checked for focusable elements before the button slots, even if the buttons appear before the content slot in the DOM.

Expected Behavior

When opening a modal, the close button only gains the initial focus if there's nothing to focus in the content slot and/or there're no button slots to focus. The order in which slots are checked is dependent on the order in which they appear in the DOM.

Reproduction Sample

https://codepen.io/nwhittaker-esri/pen/jOKvKry

Reproduction Steps

1. Visit the code sample
2. Notice the close button gains initial focus despite the modal containing focusable content and buttons
3. Enable disabled-close-button on the modal and see the input gains focus instead of the primary button

Reproduction Version

next.647

Relevant Info

Introduced by #5270.

Regression?

next.631

Impact

This regression is breaking auto-focus behaviors in our modals and causing integration tests to fail. Specifically in modals that we want to have a close button, but also want to initially auto-focus a button or some element in the content slot.

Esri team

ArcGIS Field Apps

[benelan]

The outcome of #5147 will likely impact this issue. We are looking into using delegatesFocus to ensure more consistent behavior in line with web standards and a11y. I'd have to double check, but I believe the first focusable element in Modal is the close button, which would make this expected behavior. If you want to focus the slotted content, can you do that on your end since it is in light DOM?

cc @geospatialem for any a11y insights

[geospatialem]

I'd have to double check, but I believe the first focusable element in Modal is the close button, which would make this expected behavior.

@benelan's note above is correct on the modal's close button as the first focusable element.

The change is a result of the #5270 introduction mentioned above, aligned with a11y standards and recommendations as the first focusable content in the component per WCAG Success Criterion 2.4.3: Focus Order.

The success criterion listed as Level A indicates the minimum set of a11y requirements to meet as many users will find it difficult or impossible to access information if not fulfilled.

If you want to focus the slotted content, can you do that on your end since it is in light DOM?

This is not a recommended approach since it would bypass the first focusable item and wouldn't align with what is depicted visually in the component.

Of note, there is also a timing mechanism associated with the setFocus to make it difficult for developers to set content as the focus.

[nwhittaker]

The change is a result of the #5270 introduction mentioned above, aligned with a11y standards and recommendations as the first focusable content in the component per WCAG Success Criterion 2.4.3: Focus Order.

The success criterion listed as Level A indicates the minimum set of a11y requirements to meet as many users will find it difficult or impossible to access information if not fulfilled.

Agreed, but #5270 is a backwards compatibility break of the API because it deviates from the modal's documented setFocus() behavior: "By default, tries to focus on focusable content. If there is none, it will focus on the close button."¹ On a related note, manually calling setFocus() on the modal no longer does anything unless the focusId is passed in.²

Understandable if this is more of a documentation clean-up issue, rather than a bug fix issue, though.

Footnotes

1. https://developers.arcgis.com/calcite-design-system/components/modal/#component-api-methods-setFocus ↩

2. https://codepen.io/nwhittaker-esri/pen/QWxZdwO ↩

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified on the master branch's modal readme, which will be included in the January 2023 (1.0) release.