Make AI action review usable from the keyboard without implied approval

Give keyboard review its own acceptance record

A fictional console prepares deletion proposal A-A for one draft N-A, revision R-A. The reviewer opens a short confirmation surface, inspects the stored consequence and chooses whether to continue. The practical question is whether someone using a keyboard can operate that surface without navigation being mistaken for a decision.

Fix one application-owned custom modal D-A, a short summary and exactly two ordinary command buttons: Cancel and Approve. Exclude forms, default-submit behavior, global Enter shortcuts, nested dialogs and model-generated controls. This is a proposed interaction profile, not a browser implementation. Every worksheet case is PROPOSED_UNRUN.

The existing exact-action approval contract still owns authenticated approver identity, current rights, unchanged significant fields and one-use execution. This guide adds keyboard interaction evidence before that boundary, without replacing it.

Select an entry and exit plan before wiring commands

The W3C APG modal pattern describes initial focus inside, a contained Tab/Shift+Tab sequence and Escape closing. It advises considering the least destructive initial action for difficult-to-reverse decisions. On closing, focus generally returns to the invoker, with exceptions for a missing invoker or a more logical workflow destination.

Our original policy chooses Cancel as the entry point for this short consequential review. That choice makes entry a neutral state in the application ledger. Do not use a focus notification as an approval intent. The summary must remain available for inspection; if this surface grows into a complex object list, its reviewed short-summary profile no longer applies.

Keep a trusted reference to the intended return destination. If that destination disappeared, use a separately specified logical destination rather than guessing another pending action. Returning focus records where interaction resumes, not whether the deletion succeeded.

Implement modality rather than merely declaring it

The same APG pattern calls for a named dialog and says to mark it modal only when application code prevents outside interaction and styling obscures the outside content. A declared role or aria-modal value is therefore not evidence that the necessary behavior exists.

Make actual focus ownership, background restriction and presentation part of the implementation review. A dim screenshot alone cannot establish that a keyboard shortcut cannot reach an unrelated command. Conversely, a plausible focus trace does not establish an accessible name or useful announcement.

Those actual browser and assistive-technology results remain unknown here. A future acceptance record needs the supported environment, application revision, D-A association, expected transition and observed result. Unknown evidence blocks the real positive; it is not a reason to advertise the surface as accessible or fall back to an unexplained confirmation.

Associate activation with the focused command

The APG button pattern specifies Space and Enter activation when a button has focus. It distinguishes context-dependent focus after activation and describes Cancel returning focus to the opening button. It also describes button naming and roles. These are pattern instructions, not evidence that adding a role implements keyboard handlers.

Our command mapping is deliberately small: Cancel produces dismissal; Approve produces only an approval intent for A-A/R-A. There is no shortcut that promotes any keypress anywhere in D-A into approval. Keep event ownership and the intent association in the trusted application, outside model text.

An Approve-looking caption supplied by an answer cannot join this command set. Likewise, closing after an intent was submitted cannot be the success signal. Display pending, rejected or confirmed status only from the separately supported approval service; an interaction trace cannot invent its outcome.

Use one ordinary positive keyboard trace

PROPOSED_UNRUN — symbolic interaction ledger only
Review D-A: stored A-A / N-A / R-A
Entry: Cancel; no intent recorded
Inspection: fixed consequence remains available
Navigation: declared two-command modal sequence
Explicit selection: Approve for unchanged A-A/R-A
Next state: intent submitted to independent approval checks
Effect outcome: not established by this trace

The conditional useful result is a reviewer who can inspect, dismiss or deliberately request approval using the selected commands. Actual focus behavior, supported keyboard mapping, naming, background restriction, safe content and current reviewer/session association must first be established. None is implemented by this worksheet.

Even a correctly operated interface does not prove reading, understanding or freely given consent. Keep significant action details understandable and preserve the independent backend checks when the surface appears to work perfectly.

Review eight separate decisions

Keep the claim smaller than an implementation certificate

Both references are the actual APG pattern bodies read on 1 November 2026. They display no pinned revision date or tested application environment here. They provide guidance; this article establishes no WCAG conformance certificate, browser compatibility result or deployed safeguard against accidental activation.

For these proposed cases, no dialog, DOM, keyboard event, focus transition, browser, screen reader, request, account or model operation was constructed or executed. Source-document reads and ordinary editorial file handling are separate.

Boundary is prelaunch and does not ship this modal or approval service. Its existing synthetic policy evidence concerns a different surface. A useful next result would be independently inspected implementation evidence for the selected interaction and backend association, with unknown environments named explicitly.