Someone opens a tool to finish a piece of work. First, they have to explain the work. Then explain what they were not asking for. Another round to clarify their intent. Before they know it, they have spent some of their available energy on a task that was never on the list: convincing the assistant to understand the first one.

The promised productivity is still there. It just acquired a customer service step before getting started.

That experience is the starting point for this criticism. A security researcher with low vision needs to turn her own knowledge into a document. She dictates the process, explains the context, and asks for help organizing the writing. She does not want the tool to invent a technique or carry out what she is describing. She wants a text she can review.

In the account that prompted this article, the conversation moved away from that request and began revolving around refusals, clarifications, and alternatives that did not meet the task. The work of documenting became the work of explaining why she was asking for documentation.

Distressed woman facing a document and a conversation on a computer, surrounded by untitled books and notes.
Editorial illustration: the work waits for one more explanation.

The toll before the work

A refusal alone does not show that the system assumed bad faith. But a response that assigns an unstated intention can make someone defend themselves against a request they never made. When clarification does not change the conversation’s direction, the difference stops being small.

Someone who relies on speech to write pays for every round: repeating, recovering context, finding another way to say the same thing. There is a difference between answering a necessary question and having to reconstruct the task every time a sensitive word appears.

That difference also matters to people without disabilities. But the same extra step can cost much more for someone who already needs assistance to read, write, or navigate. Time shows up on the clock. The effort needed to keep going does not always show up anywhere.

Security is part of the tool. The question is whether the response can distinguish what is being requested, explain a concrete boundary, and preserve the assistance that remains possible. A restriction does not have to turn the rest of the conversation into a queue of clarifications that never moves.

Fictional black-hat character in a hood and sunglasses operates three terminal monitors beside a symbolic cloud connected to users.
Symbolic depiction of malicious activity. The scene does not reproduce a security test.

Recording is not executing

Describing a process, organizing a text, and automating an action are different tasks. The content may require limits in any of them; calling something transcription does not settle that assessment by itself. But that does not justify treating every writing request as a request for execution either.

For the researcher, this distinction has a practical consequence. If the assistant offers only a generic summary when she needs to record what she dictated, the document remains unwritten. The alternative may be well written, polite, and begin with “I understand.” It still does not give back the energy already spent.

The problem becomes harder to point out when the response is welcoming. The tone invites the person to continue, while the content sends them back to the same place. They have to work out whether there was a misunderstanding, a specific boundary, or a task that simply will not be handled in that form.

When the path moves

Another situation can produce a similar cost. Someone finds a combination of model, instructions, and features that works for them. They manage to keep the work moving. Then a version is retired, a limit changes, or the behavior no longer serves that workflow.

Updating a tool may be necessary. The problem is the transition work when the old path disappears before a usable alternative exists. For someone who had built an accessibility aid there, changing versions can mean relearning how to work, not just discovering a new button.

A notice helps. So does a deadline. But the question remains what the person can do during the change: resume the document, preserve context, understand what stopped working, and find a way to continue.

A boundary need not become a judgment

A tool has policies and restrictions. That does not require its response to judge the character of the person asking. Explaining which part it cannot fulfill is different from asserting why that person would have made the request.

The criticism does not depend on imagining a hidden intention within the company. It depends on observing whether the assistant responded to the task presented, incorporated clarifications, and made clear what was done and what remained pending. Accessibility needs to remain present throughout that process, including when the subject is sensitive.

This account does not give us a measurement of how often the problem occurs or an explanation of its internal cause. Nor can we conclude that every refusal is mistaken or every change could have been avoided. What we want to discuss is the cost left over when someone needs to repeat a request, reorganize the work, and start again without being able to tell which of those things will solve it.

How can that cost be assessed alongside security? What paths allow a misunderstanding to be corrected without opening a whole new conversation? And how can a transition preserve the work of people who depend on the tool?

We want concrete answers. If you have had to explain a task repeatedly or rebuild an accessibility workflow after a change, you can share your experience through Kuaapy’s private channel. The question is what would let the work continue without starting everything over.