Accessibility changes the product requirements

An application promises broad access, but installation assumes a powerful computer, familiarity with a terminal, and enough spare time to diagnose model downloads. The interface may be attractive once everything works. The people excluded during setup never reach that interface.

In the Cassette planning discussion, I rejected a proposed initial audience of technically sophisticated Mac users because it violated the project’s social-good commitment. Cassette was being developed as a model platform, and the proposed commercial product needed a route that ordinary consumers could use. That correction changed the audience the architecture was supposed to serve.

I also specified an intended product spanning several operating systems and an accessible web route, with the agent handling setup and external-tool integration. Those statements establish product intent. They do not establish that the cross-platform product, subscription, or setup automation had been delivered and validated.

Translate the audience into a task

An accessibility commitment needs observable requirements. Identify who should be able to begin, what equipment and connectivity they may have, which interactions they need to complete, and what happens when the preferred local route is unavailable. Avoid assuming that one successful installation represents the full audience.

A setup flow should explain what it is doing and make consequential choices understandable. If it needs storage, an account, or a download, the person should know what is required before committing. If a route involves an additional cost or a transfer of data, disclose that at the point where the decision is made.

The recovery path matters as much as the first attempt. A user who stops halfway through setup should be able to resume without repeating every decision. A failed download should preserve a clear state and a useful next action. Technical detail can remain available for diagnosis without becoming a prerequisite for basic use.

An illustrative acceptance session

Consider a hypothetical person using an older laptop to organize a small collection of public documents. The proposed application begins by checking available resources. The preferred local model cannot run within the available memory. The application explains the limitation and presents a supported alternative, including any changed privacy or cost conditions.

The person chooses whether to continue. The application retains the imported document list and the work already completed. If the person declines the alternative, they can exit without losing their source files or being trapped in an unfinished setup screen. This is a proposed test scenario, not an observed Cassette session.

Run the same task using keyboard navigation and a screen reader. Check whether the resource warning is announced, whether focus reaches the available choices in a sensible order, and whether the person can return to the previous step. A successful mouse-driven demonstration cannot establish those behaviors, particularly when a warning appears visually but is never announced, or when the available choice cannot receive focus and the person has no supported way to continue.

Then interrupt the network during a required download. The interface should distinguish a temporary interruption from an unsupported device. On resumption, it should explain what remains and avoid presenting a fresh, unexplained error as though the user had made a new mistake.

Test exclusions as design failures

A useful acceptance matrix records the user task, environment, expected behavior, and evidence from the session. Include resource limits, input methods, account state, connectivity, and interruptions where they affect the intended audience. The matrix should identify untested combinations rather than marking the whole product ready after one favorable demonstration, so that an intended user can tell whether the route they need has actually been exercised under relevant conditions.

Ordinary-user access and disability access overlap but are not interchangeable. Reducing setup complexity does not prove screen-reader usability. Supporting keyboard input does not establish affordability or access on a low-resource device. Define the relevant requirements separately and test each with appropriate participants and methods.

Some constraints may require a narrower initial release. State that scope accurately and preserve the broader commitment as unfulfilled work. A staged rollout can be responsible when its limits are explicit; it becomes misleading when the tested audience silently replaces the audience the product promised to serve.

Before adding another advanced capability, select one essential task and test it across the access routes the release intends to support. Record where participants need outside help, where recovery fails, and which conditions remain untested. Use those findings to change setup and fallback behavior before claiming that the intended audience can complete the task independently.

Source notes

Based on the August 2026 Cassette audience correction and product requirements. Accessibility sessions and fallback behavior are proposed acceptance exercises, not verified product capabilities.