Access Is the Interface

A story-world as a design space

A garden inside the lab

UMADA is my Afrofuturist speculative-fiction project. This garden is part of a laboratory where scientists have made chimera children through many kinds of technology. We do not need to explain the science to enter the story: these children are living, growing people, learning what their changing bodies can do and what they need.

No two bodies in the garden are alike. Each has its own capacities, limits, and ways of sensing. A child may travel on wheels, use a responsive prosthetic limb, or notice the world through vibration, sound, light, or touch. They are learning their bodies’ rhythms, needs, and possibilities. Children and adults share the lab; the children make this garden their own.

Three ways of being in the garden

Something is coming

A blast is approaching the lab. The children do not know it is coming. We are outside the garden, working inside a bounded coding sandbox. For now, we can offer a shape or words. We can imagine other objects—a light, signal, or character—and ask what would make each useful. We do not know in advance what will help. Participants can ask, test, and document what happens.

The garden is a Faraday-cage metaphor for that boundary. Each object changes only this local p5 scene. It cannot call a tool, send a message, or leave the garden. Its purpose and description are visible; movement stays paused until someone allows it, and a person can stop it. The children remain the authors of their world.

Participants can make an object, explain its intention, add text alternatives, try an interaction, and inspect the resulting code and decision trail. The question is not only “Can we build it?” It is also “Who asked for it, who decides whether it helps, and what should it never do?”

Workshop question: How can we offer help inside someone else’s world without taking control of it?

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.