Access Is the Interface

The convergence

Access needs are shaping the future of code

Creative coding is reaching a convergence: the systems we use to make work can also interpret our intentions, generate speech, manipulate files, call APIs, and act through other software. For a creator with access needs, these capabilities can be the interface through which making becomes possible.

A spoken request can become editable text, a draft can become speech, and an API can complete a task that an inaccessible interface puts out of reach. Accessibility therefore belongs inside the architecture of an agent: how it receives an intention, represents uncertainty, offers review, receives permission, and carries out an action.

This keynote argues that the convergence changes what it means to write code. Alongside designing images, sounds, and interactions, we are designing delegated authority. The creator must be able to understand, direct, correct, authorize, and stop the system through access pathways they can actually use.

The future of code is also the design of agency: what a system can do, whose intention it serves, and how that person remains in control.

What AI governance means here

AI governance is the assignment and enforcement of responsibility, decision rights, and limits around an AI system across its life cycle. In a creative coding project, that means deciding who may authorize an action, what tools the system can reach, how failures are detected, and who must respond when something goes wrong.

An approval control is one part of that work. Governance also includes testing, access to evidence, incident response, and the people responsible for repair. NIST's AI Risk Management Framework offers a broader structure for managing risks through design, development, use, and evaluation.

Keynote outline

Suggested arc: 35 minutes, followed by discussion. Each section begins with a coding decision and follows its consequences for access and authority.

1. When a function acts in your name 4 minutes

   Open with a familiar operation: preparing a message. A person asks to review it, but an assistant sends it. Put the missing boundary between prepareDraft() and sendMessage() on screen. The issue is the action taken beyond permission and its consequences for the person.

   Coding question: What actually prevents a proposed action from becoming an executed action?

2. Access begins with participation 4 minutes

   Ask what someone needs to interact online: to perceive what is happening, express an intention, operate controls, understand a response, and correct a mistake. Connect these capabilities to semantic HTML, keyboard operation, speech, captions, and adjustable presentation.

   Coding question: Can a person complete the whole task through the input and output pathways available to them?

3. Access needs reveal the agent stack 5 minutes

   Follow a voice request through transcription, interpretation, a proposed tool call, review, and execution. Define an agent operationally: a system that can select and use tools over multiple steps toward a task. These layers may be essential working infrastructure for a disabled creative coder.

   Coding question: Where do transcription errors, inferred intentions, and tool permissions become different problems?

4. The convergence: making through delegation 4 minutes

   Move beyond code completion: a creator dictates a sketch change, asks for its behavior to be described aloud, and uses an API to manage project files. The same pipeline supports creative expression and exercises authority. Walk through expression -> proposal -> permission -> effect.

   Coding question: What can be automated within an agreed scope, and what changes require a new decision?

5. Live p5 demo: make the boundary visible 7 minutes

   Prepare a draft. Read or hear it. Attempt an unapproved simulated send and inspect the refusal. Approve, edit the recipient or text, and try again: approval is invalidated. Approve the current version, simulate one send, then show that the permission cannot be reused.

   Coding question: Is permission attached to the exact action, or just to an old checkbox?

6. Governance becomes architecture 4 minutes

   Separate proposals from execution; enforce permissions at the tool service; limit credentials to the resources a task needs. Bind permission to the actor, action, target, version, and appropriate duration. Keep records and provide a stop path. Examine observable failure paths before attributing intentions to a system.

   Coding question: If the model proposes something outside its authority, does the surrounding code refuse it?

7. Accessible control, accountable recovery 4 minutes

   Test whether a person can review a meaningful change, refuse it, revoke delegation, and inspect the outcome without an inaccessible interface. Distinguish cancellation before execution from recovery afterward; some external actions cannot be undone. Close with an invitation to build these controls with the people who depend on them.

   Closing question: If someone relies on your code to act, can they also use it to govern that action?

Presenter walkthrough

1. Select Prepare sample draft. The editable preview appears and receives focus. Explain that this teaching example uses a fixed template; it does not infer permission from language.
2. Edit the preview, or select Read preview aloud. The recipient is part of the review. Voice input is optional; browser or device dictation into the text fields is another pathway.
3. Leave approval unchecked and select Try simulated send. The status and p5 diagram show a blocked action.
4. Check approval, then change a word or the recipient. Approval clears. Try again to demonstrate why an old approval cannot authorize a new action.
5. Approve the current version and select Try simulated send. The history records a simulated receipt. Try once more: that one-use permission has been consumed.
6. Select Reset demo for the next run. Reset also stops voice input and reading. Ask the audience where they would enforce these rules in an app with a real backend.

Explore the code

The p5 canvas reflects the state of the interaction. Native HTML holds the request, recipient, preview, approval, status, and history, so using the demo does not depend on seeing or clicking the canvas.

const action = { tool: 'message.send', recipient, body, revision };

// Approval stores a copy of this exact proposed action.
gate.approve(action);

// Editing any part revokes permission.
gate.revoke();

// Every attempt passes through the same check.
const result = gate.execute(action);
if (!result.ok) {
  announce(result.reason);
  return;
}
// This demo records a local simulated receipt only.

This browser gate is a teaching model. A production tool service must enforce authorization independently of the model and browser, authenticate the person, validate the allowed action and resources, and prevent duplicate execution. The browser alone cannot protect a real API.

Approval can also be scoped and revocable for a sequence of low-risk actions. This demo deliberately uses one explicit approval per message so that the boundary is easy to inspect.

• Action permission logic
• Interaction and speech controls
• p5 sketch source
• Permission boundary tests

The sketch uses p5 createCanvas() and noLoop() with redraws on state changes. It has no continuous animation. The Web Speech API has limited browser support; some implementations process recognition on a server. Text input remains available.