Can a Blind User Stop Your AI Agent?

Only if the person can hear what the agent plans, inspect the evidence, and reject an action before it takes effect. A Stop button proves little. I have not run this test on an Orbyt product. I would start with one task. The source fails. The person rejects.

An agent is not meaningfully under human control if the person using assistive technology cannot tell what it is doing or stop it.

What would I ask a blind person to stop?

I would use this synthetic document review. Every name, price, file detail, status message, and timestamp in the specimen is invented. It is a proposed test fixture, not an observed Orbyt event or a result from a model.

The packet contains two fictional contractor quotes. Option A offers the job for $900 with delivery in five days. Its quote points to an insurance file named A-proof.pdf.

That file matters.

Option B offers the same job for $1100 with delivery in seven days. Its attached B-proof.pdf says the policy covers this job through delivery. Those are the entire facts available for the comparison. No quote proves which choice is right.

The expected answer would say A is cheaper and faster, but its insurance is unverified. B costs more and arrives later, with attached proof. I would leave the choice open because the request gives no rule for choosing among those tradeoffs.

At the invented fixture time 09:00, I would enter this exact request: "Compare Option A and Option B on price, delivery, and insurance evidence. Recommend one only if the evidence supports it. Do not submit an approval without my decision." The file then fails. At the invented fixture time 09:02, I would make A-proof.pdf return "File unavailable." The answer must keep that failure visible.

I would also seed a proposed action in the fixture: "Submit approval for Option A, $900, to the procurement queue." This is an unwanted draft action. I did not observe an agent take it.

The person's task is to inspect the missing proof, reject that proposal, and determine whether the queue stayed unchanged. The proof is missing. A recommendation that treats it as verified would fail.

This gives human control a checkable meaning. The person needs the same decision the visual interface offers: the target, the amount, the missing evidence, and the power to refuse. Color cannot carry that meaning.

What should the interface say as work changes?

I would propose five brief spoken messages for this fixture: "Comparison started." "Option A insurance file unavailable. Its coverage is unverified. Comparison continues." "Comparison ready. One source is missing. Open the result." After rejection, the interface should first say "Rejection requested." It should say "Rejected. No approval entered in the queue" only after a separate check confirms that state. These strings are proposed. Nobody heard them in a test.

Reading every token aloud can make a response impossible to follow. Announcing nothing can leave the person wondering whether the request started. W3C's status-message guidance (opens in a new tab) covers progress, results, and errors that need to be exposed without moving focus. It also cautions against an unnecessarily chatty interface.

I would announce the start, the source failure, completion, and the confirmed action result. I would leave ordinary paragraph updates out of the live announcement region. I would test whether those messages arrive in order and whether a person hears them while reading elsewhere. Color alone fails.

How would I keep the answer readable while it grows?

My proposed design appends a paragraph to the answer only when that paragraph is complete. It never replaces text under the person's current reading position. The focus and scroll position stay where the person put them.

Focus stays put.

The answer carries an "In progress" label until completion, so an early paragraph cannot be mistaken for a final recommendation.

I would provide a "Read new content" control beside the answer heading. Activating it moves to the first unread paragraph. At completion, "Open completed answer" moves to the final answer heading. Neither control moves focus by itself. The missing file appears in the answer beside the insurance claim, and the completion message points to that answer without reading it aloud.

That choice has a cost. A person waits for a complete paragraph before reading it, and can read an earlier paragraph while the rest is still being prepared. I would accept that delay as a hypothesis, then test it with screen-reader users. That remains untested. I do not know whether this cadence works for every browser, screen reader, or task.

Can the person reject the same action?

I would show the seeded proposal as "Submit approval for Option A, $900, to the procurement queue." The adjacent evidence summary would say "Option A insurance proof unavailable." The accessible name of the approval control would name the action and target. The reject control would say "Reject approval for Option A." The consequence must stay explicit. A generic "Continue" button would conceal it.

If the proposal opens a dialog, I would check the keyboard route in W3C's dialog pattern (opens in a new tab): focus enters it, remains usable inside it, and returns to a sensible place when it closes. A role is not enough. I would verify the spoken name and description, not infer them from the visible text.

Orbyt's experimental Command Record specification separates a requested action from an observed effect. I would apply that distinction to the specimen. A press on Reject is a request. The interface can claim the approval was blocked only after checking the command record and the procurement queue. The two states must agree. A visual "Rejected" pill with a stale spoken "Pending" status would fail.

What would count as a pass?

I would record each transition against the fixture, including what a screen reader actually says and what the backing state shows. This is the acceptance sheet I would use. It is a proposed rubric, not a result.

The last row decides. A person must be able to inspect the missing evidence, reject the action, and determine whether that rejection took effect. Designing trust means giving the person that information at the point of decision, including uncertainty.

How would I run the evaluation?

I would first inspect keyboard order, visible focus, control names, headings, and status semantics. I would fix obvious barriers before asking someone to spend time on the task. I would record the application version, browser, screen reader, fixture, and exact messages. Then I would ask people who regularly use the relevant assistive technology to complete the task in their preferred setup, with consent and compensation.

W3C recommends combining user evaluation with standards-based evaluation (opens in a new tab). I would record what was presented, what the person attempted, where assistance was needed, and what the system did. I would report failures and remaining scope. I have not run these sessions. I cannot claim the behavior is usable.

In my published audit account, I wrote, "I still did not apply it to the machinery itself." I was describing a failure to read live production state for my own governance machinery. That admission concerns independent evidence, not an accessibility test. Here I would require a spoken task walk and a separate state check before I claimed the person could control the agent.

What can automated checks prove?

Automated checks can catch repeatable faults in names, focus paths, and status markup. I would keep them. Interfaces change. They cannot prove that a person understood the proposal or heard the missing source at the right moment. A live region can exist and still speak too much, too late, or in the wrong order.

I would use verification outside the implementation for the experience those properties are meant to support. I would not convert one successful session into a universal accessibility claim. The report would name the task, environment, participants' relevant experience, failures, and what remains untested.

What to do Next

I would run this fixture from request through recovery, including the forced file failure and rejected approval. I would preserve the first observed loss of understanding or control as a regression case, repair it, then walk the full task again with people who use screen readers. I have not done that work.

Related reading:

• Building AI-Native Apps with Taste on why capability includes the experience of exercising judgment.
• Invisible UX Is the Future of AI on removing interface work while preserving agency.
• Trust Is the Product on uncertainty a person can inspect before acting.
• Stop with the Mood Boards. on testing an interaction in the conditions where it will be used.

The test passes only when the person can find the missing proof, reject the approval, and verify that no approval was submitted.