Modal focus trap

Silktide identifies pages that contain a modal dialog - a popup that blocks interaction with the rest of the page - and asks you to verify that keyboard focus is managed correctly while the dialog is open. This is a manual review: automated testing can find the dialog, but not observe how it behaves when opened and closed.

Why this matters

While a modal dialog is open, the page behind it is visible but inert. If can escape the dialog, keyboard and users end up tabbing through content they cannot see or use, reading the page underneath out of context, and losing their place entirely. And if focus is not returned when the dialog closes, they are dropped at the top of the page and must navigate back to where they were.

How to fix it

Open each dialog on the page and verify with only a keyboard:

When the dialog opens, focus moves into it - typically to the first control or the dialog itself.
Pressing Tab and Shift+Tab cycles through the dialog's controls without ever reaching the page behind it.
Pressing Escape closes the dialog (for dialogs that can be dismissed).
When the dialog closes, focus returns to the element that opened it.

If any of these fail, correct your dialog implementation. The native <dialog> element opened with showModal() provides most of this behavior for free; custom dialogs need it scripted. If everything behaves correctly, the finding.

How Silktide tests this

Look for signs that a page contains a modal dialog: a native <dialog> element, an element with role="dialog" or role="alertdialog", an element with aria-modal="true", or an element with a customary modal-style class name that also contains focusable controls.
When any of these are found, raise one review prompt for the page.

Silktide cannot open the dialog and observe its runtime focus behavior, so this check never fails automatically - it asks you to verify.

Troubleshooting

Many sites ship dialog markup in every page (a newsletter popup, a cookie dialog, a hidden search overlay) that only appears in certain conditions. The prompt still applies: verify the dialog's behavior in the state where it opens. If the markup is a leftover that can never open, consider removing it.

Our dialogs come from a third-party library

Well-known dialog libraries usually manage focus correctly, but configuration and custom content can break it. Verify the behavior on your own pages rather than relying on the library's documentation.