Use case

Accessibility automation

Drive web tasks on a user’s behalf and audit pages for accessibility — over a token-efficient view of the live DOM.

The problem

What the status quo costs you.

Inaccessible sites lock people out of routine tasks, and accessibility audits are slow, manual, and stale the moment the page changes. Both problems need something that can reliably understand and operate a live page on a user’s behalf — not a brittle script that breaks on the next redesign.

See how Twin works
app.example.com
  1. Open the page on the user's behalfdone
  2. Map interactive DOM elementsrunning
  3. Complete the task or auditqueued
  4. Hand off if a step needs a personqueued
  5. Record live view + videoqueued
A Twin run for accessibility automation — compile once, then replay on a cache hit.

The wedge

Compile once. Replay forever.

Twin’s DOM-to-indexed-state compiler turns a live page into a compact, structured map of its interactive elements, which is exactly the foundation both assistive task-completion and accessibility auditing need. You can compile a "complete this task for the user" flow into a replayable skill, or sweep pages and report on their interactive structure — all where you’re authorized, with audit logging on every call.

  1. 1Express an assistive task as a goal; Twin operates the live page over its indexed DOM map and completes it on the user’s behalf.
  2. 2Compile recurring assistive flows into skills so they replay deterministically and cheaply.
  3. 3Sweep target pages to surface their interactive structure for accessibility review.
  4. 4Pause for human-in-the-loop handoff whenever a step needs a person, then resume.
  5. 5Keep runs observable with live view and durable session video for review and evidence.

Outcome · Assistive task-completion and accessibility auditing run on the same structured, token-efficient view of the page — illustratively turning manual, redesign-fragile audits into repeatable, replayable skills that stay cheap to run.

In practice

The actual call, and what it returns.

Both jobs read the same thing: a compact, numerically-indexed map of the page’s interactive elements. Observe it to audit, or act on it to complete the task for someone.

Observe + runassistive-task.shbash
# Read the page as indexed state, without touching it.
curl https://twin-browser.com/api/v1/observe \
  -H "Authorization: Bearer $TWIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://clinic.example.com/book" }'

# → 200 the interactive elements, indexed: [1] link, [2] button, [3] select …

# Or complete the task on the person's behalf, pausing when a step needs them.
curl https://twin-browser.com/api/v1/run \
  -H "Authorization: Bearer $TWIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://clinic.example.com/book",
    "prompt": "book the first available appointment on Tuesday morning",
    "success": { "kind": "textVisible", "value": "Appointment confirmed" },
    "hitl": true
  }'

What this call does

  • Observe never acts — it is the audit read, and the cheapest call on the API.
  • The planner acts on those indices rather than CSS selectors, so a cosmetic redesign does not invalidate the flow.
  • "hitl": true hands the run back to a person the moment a step genuinely needs one.
  • Every run can be watched live and replayed afterwards from its recording, which is the evidence an audit wants.
Every endpoint, every field

FAQ

Accessibility automation on Twin — common questions.

How does Twin help with accessibility?
Twin’s DOM-to-indexed-state compiler produces a structured, numerically-indexed map of a page’s interactive elements. That same map powers completing tasks on a user’s behalf and auditing pages for interactive structure, where you’re authorized to do so.
Is automated assistance allowed?
Twin automates the web where you’re authorized — first-party sites, operator-approved automation, accessibility, and authorized testing. The run’s target URL is the authorization signal, with auth, billing, and audit logging on every call.
Can recurring assistive flows be made cheap to run?
Yes. Recurring flows compile into skills that match the semantic dispatch cache and replay deterministically with zero LLM calls, so the marginal cost per run trends toward zero.

Put accessibility automation on autopilot.

Start free, hand your agent the work under your guardrails, and let the runs you repeat replay from a compiled skill.