Build an Accessible Plan-Diff Review Before an AI Agent Calls a Tool

An AI agent revises its plan after a test fails. If the interface silently replaces the old text, can the reviewer tell that a new tool permission appeared?

Treat every revision as a versioned diff, not a refreshed paragraph:

type PlanVersion = {
  id: number;
  added: Step[];
  removed: Step[];
  permissionChanges: PermissionChange[];
  approvedVersion?: number;
};

The review surface needs a logical heading, summary, and focus order:

<h2 id="plan-title">Plan revision 3</h2>
<p role="status">2 steps added; terminal access expanded.</p>
<section aria-labelledby="plan-title">...</section>
<button>Approve revision 3</button>
<button>Reject and explain</button>

Do not move focus automatically when a revision arrives. Announce the status, preserve the reviewer’s position, and provide a shortcut to the change summary. If revision 4 arrives while revision 3 is open, disable the stale approval button and explain why. Color cannot be the only signal for additions, removals, or authority changes. Store the reviewer’s draft comment across that invalidation so safety does not punish careful feedback.

The W3C technique for role="status" shows how status updates can be exposed without taking focus. It is only one part of the pattern; keyboard navigation, semantic diff labels, cancellation, and screen-reader testing still need explicit QA.

This component can serve as an external acceptance pattern for long-running coding platforms such as MonkeyCode. Its cloud service is currently free to start, making a disposable browser-flow review possible, but this article does not claim its current UI has or lacks these behaviors.

I am a MonkeyCode user, not affiliated with the project. This account shares an operator with the other batch accounts.