Agentic actions

An agent is an AI system that takes actions toward a goal, such as calling tools, navigating, filling forms, editing files, or making purchases, sometimes across many steps and sometimes without confirming each one. This is the hardest pattern for accessibility, because the usual assumption that the user acts and the interface responds no longer holds. The system is acting, and the user has to stay in control.

Key points

An agent acts on the user’s behalf, which breaks the usual assumption that the user acts and the interface responds.
Announce meaningful agent steps through a status or log region, at the level of steps rather than every internal tick.
Make the agent interruptible with a keyboard-operable stop that works mid-step.
Make actions reviewable and reversible, and confirm consequential actions before acting.
Whatever the agent produces must be accessible, and an agent workaround is a bridge, not a reason to leave a product inaccessible.

Keep the user inside the loop

The interaction loop from the foundations still has to close, even though the agent is driving. The user needs to perceive what the agent is doing, step in to stop or redirect it, and review and undo what it did. If any of those is missing for a screen reader or keyboard user, the agent is operating on them rather than for them.

Announce what the agent is doing

Each meaningful action should be perceivable as it happens, not only shown as a moving visual. Announce steps such as searching, opening a file, or sending a message through a status or log region so a screen reader user can follow along. Keep these announcements at the level of meaningful steps rather than every internal tick, to avoid the flooding problem described in Dynamic and streaming output.

Make it interruptible

A user must be able to stop the agent at any point with the keyboard, without reaching for a mouse and without waiting for the current step to finish. This is the same stop requirement as for streaming, covered in WCAG Operable, and it matters more here because the agent is changing things in the world.

Make actions reviewable and reversible

People need to see what the agent did and undo it. GitHub Primer’s Copilot principles put this well, calling for AI features to be flexible and forgiving, with the ability to review, reverse actions, and keep a history. For consequential actions, confirm before acting rather than after, and present that confirmation as accessible content with real controls.

The results of actions must be accessible

Whatever the agent produces has to be reachable. A file the agent created has to be a real, focusable link or control, not text that looks like one. One blind user documented an AI tool whose generated download was plain text rather than a link, so the file could not be reached at all with a screen reader. An action is not complete if its result is not accessible.

Workarounds are not a substitute for access

Agents are sometimes used to drive software on a disabled user’s behalf, for instance performing a mouse action the user cannot. A demonstration on the Blind Access Journal showed an AI tool dragging components in an interface that was not otherwise operable for the user. This can genuinely help, and it can also let a vendor avoid making the software accessible in the first place. Treat an agent workaround as a bridge, not a reason to leave the underlying product inaccessible.

Audience: Engineer

Give the agent an action log in a managed live region that announces meaningful steps, not every internal call, and a keyboard-operable stop that cancels mid-step. Build undo and a pre-action confirmation for anything consequential, and make those controls real, focusable, and named. Ensure every artifact the agent creates is rendered as an accessible element, with files and links as real files and links.

Announce meaningful steps in an activity log, keep a persistent stop, and offer undo plus a real link to whatever the agent produced.

<!-- Append-only log of meaningful steps, not every internal call -->
<div role="log" aria-label="Agent activity">
  <p>Searched your project files.</p>
  <p>Drafted a summary of report.docx.</p>
</div>

<button type="button">Stop</button>
<button type="button">Undo last action</button>

<!-- The result of an action is a real, focusable link -->
<a href="/files/summary.docx" download>Download summary.docx</a>

Audience: Product Manager

Decide where the agent must ask before it acts, and treat reversibility and an accessible audit trail as requirements rather than extras. Remember that the organization owns what the agent does, so an action a user could not perceive or stop is both an accessibility failure and a liability. If you offer an agent as an accessibility workaround for another product, plan to fix that product too, rather than treating the workaround as the fix.

Audience: Self-advocate

An agent can be freeing, letting you accomplish things that an inaccessible interface blocked, much like building your own tool. It can also be unnerving if you cannot tell what it is doing, cannot stop it, or cannot undo a mistake it made in your name. The agents worth trusting narrate their steps, stop when you say stop, and let you review and reverse what they did, all without a mouse.

Audience: Designer

Design the agent’s state so it is legible to everyone, showing what it is doing now, what it has done, and what it is about to do, in text and not only in motion. Give prominent, persistent stop and undo affordances, and design confirmation moments for high-stakes actions so the pause is clear in the accessibility tree and not just visually.