The screenshot misses the difficult part

A modal can have excellent typography, a soft backdrop and a neatly aligned close button while still losing the user's place. The failure may appear only after cancellation, after a request fails or after the action removes the button that opened the dialog.

Consider a saved-skills page. Each card has a Remove button that opens a confirmation. If removal succeeds, the card disappears. Where should keyboard focus go next?

That is a product decision, not a decorative detail. Ask an interface-building agent to specify the complete focus journey before accepting the component.

Methodology and scope

This guide was checked against the W3C modal-dialog pattern, MDN's native dialog reference and W3C's explanation of Focus Not Obscured on September 14, 2026. It is intended for teams reviewing agent-generated interfaces.

We propose a saved-item removal exercise. We did not execute it against OpenAgentSkill or another live application, run a screen-reader audit or establish WCAG conformance. The examples are acceptance criteria to adapt to your product.

The selection criterion is a user-visible state transition: what opens the dialog, what happens inside it and where the user resumes. This is narrower than a complete accessibility audit and more informative than approving a static screenshot.

Write the journey before choosing the component

The W3C modal-dialog pattern describes moving focus inside on opening, keeping the tab sequence within the modal and supporting Escape to close. On closing, focus normally returns to the invoking element; if that element no longer exists, it should move somewhere logical in the workflow.

For our example, decide the destinations in advance. Cancellation should preserve the card and its removal trigger. Successful removal needs a destination that still exists, such as the next card's heading or the collection heading when no cards remain. The appropriate choice depends on the surrounding interface.

Also decide the initial target. For a difficult-to-reverse action, starting on the least destructive choice can be preferable. Do not let a reusable component's incidental DOM order make that decision for the whole product.

Check the opening mechanism, not just the tag

MDN's dialog reference distinguishes a native dialog opened with showModal from one displayed non-modally with show or the open attribute. A native modal supplies important browser behavior, including making the surrounding document inert. A custom implementation must supply the expected behavior itself.

Our recommendation is to use an established component or native mechanism that fits the application, then verify its actual behavior. Merely adding a dialog role or dark overlay does not demonstrate that background controls are unavailable.

Give the dialog a meaningful accessible name and a visible closing control. Check the resulting interface rather than treating the component library's reputation as evidence for this particular integration.

Use three outcomes, not one happy path

Build the review around a disposable saved item in a non-production fixture. Give the item a distinctive name so a reviewer can tell which card is affected. Do not test removal on real user data merely to obtain a screenshot.

Specify three outcomes:

Cancel: the collection is unchanged and the user can continue from the original card.
Confirm and succeed: only the selected card disappears, the dialog closes and the user resumes at the chosen surviving destination.
Confirm and fail: the item remains, the failure is understandable and the interface offers a deliberate next action.

Keep closing separate from committing. A backdrop click or Escape should not accidentally activate the destructive operation. If the product allows dismissal while a request is running, specify how the eventual result will be communicated. If it does not, explain that state and make sure the user is not stranded indefinitely.

These are proposed product checks, not claims that every modal needs identical cancellation semantics.

Try the disappearing-trigger case deliberately

The removable-card example exposes a bug that a generic open-and-close demonstration can miss. A component may remember the opening button but try to restore focus after that button has been removed.

Ask the agent to explain what happens when the selected card is the first, middle, last and only item. Use the same action each time, but change the surrounding state. For the last item, do not rely on a nonexistent next sibling. For the only item, consider the empty-state heading or another useful surviving control.

Then repeat with a filter active. The destination should make sense in the currently displayed collection, not in an outdated list. If the interface rerenders or reorders cards, check that the chosen destination still belongs to the intended workflow.

Inspect visibility as well as focus location

The Focus Not Obscured explanation describes an AA requirement that an interface component receiving keyboard focus not be entirely hidden by author-created content. Complete visibility is a stronger design objective; do not confuse those two thresholds.

For this review, include a narrow viewport, increased zoom and a long confirmation message. Inspect whether a sticky header or action footer covers the focused control. Repeat after the dialog closes, when focus returns to the collection.

A screenshot can supplement the check, but the reviewer should record the action that produced it. An attractive image of the open dialog says little about a hidden control encountered several Tab presses later.

Require a state log in the handoff

Ask for a compact log containing the starting item, action, expected destination, observed destination and result. Include browser and assistive-technology versions when those were actually used. Mark untested combinations as untested.

Record request behavior separately from focus behavior. A successful backend removal does not prove a usable return path. Likewise, a well-managed dialog does not prove the request targeted the correct item.

The OpenAgentSkill directory can help you discover interface and accessibility skills. Judge candidates on whether they deliver inspectable behavior evidence, not whether they repeat the phrase accessible modal.

Limitations

This focused exercise does not cover every dialog type, mobile interaction, nested overlay or assistive-technology combination. Avoid declaring the entire application compliant from a single passing fixture.

Our form error-recovery review covers labels and submission feedback. This workflow adds the lifecycle around an overlay: entry, cancellation, completion and return. The final question is simple: after the agent's component does its job, can the user still tell where they are and what to do next?