Curbcut

Scanned Workspace
Mechanical Repair Preview
Verified Mechanical Repair
Blocked Agent Action
Contextual Proposal
Responsive Workspace

Inspiration

Accessibility scanners are good at finding problems, but finding them is only the beginning. A developer still has to find the correct source code, understand the evidence, choose the correct repair, preview its effect, and check the result.

We built Curbcut around the question: What if the developer and an external browser agent could work together on the same live accessibility workspace?

The agent could handle repetitive technical work, while the developer maintained authority over changes that require meaning, context, or design judgment.

What it does

Curbcut is a browser-native accessibility repair workbench for static HTML and CSS.

The workspace keeps everything together:

Editable source
A securely isolated live preview
Real axe-core accessibility findings
Exact source mapping and rendered-element highlighting
Proposed code diffs
A rendered preview of each proposed repair
Human approval for semantic changes
Fresh verification scans
Exact Undo and clean source export
A shared timeline of human and agent actions

axe-core scans the actual rendered preview, and the results aren't hard-coded. Selecting an issue focuses its exact source range and highlights the corresponding element in the preview.

Every repair begins as a non-mutating proposal. Curbcut shows the exact source diff and proposed visual result before changing the working source.

Technical repairs, such as removing a positive tabindex, can be applied and verified in the code directly. Contextual repairs, including form labels, image alternatives, button names, and document text, remain blocked until the developer reviews and approves the exact proposal.

If the browser agent attempts to apply a contextual proposal early, Curbcut returns APPROVAL_REQUIRED, visibly records the blocked action, and leaves the source unchanged.

Curbcut exposes ten focused WebMCP tools covering the real workflow: workspace inspection, scanning, listing and inspecting issues, previewing, applying, rejecting, undoing, summarizing, and exporting. These tools operate on the same React store and preview used by the visible interface. There is no arbitrary JavaScript tool, arbitrary DOM mutation, or whole-document AI rewrite.

How we built it

Curbcut is a browser-only React 19, TypeScript, and Vite application deployed as a static site on Vercel. It requires no account, backend, or database, and the developer’s source stays local to the browser.

We use parse5 8.0.1 to parse canonical HTML with source locations and assign revision-bound internal node IDs. Mapping metadata is added only to generated preview markup, so it never contaminates the working or exported source. Repairs use validated raw-offset patches that preserve unrelated source text.

Imported HTML is treated as untrusted. DOMPurify sanitizes it before it enters an iframe with sandbox="allow-scripts" and no same-origin permission. A nonce-based Content Security Policy blocks network requests, navigation, forms, embeds, and untrusted scripts.

axe-core 4.13.0 runs inside that opaque preview realm. A validated postMessage bridge connects scanning and highlighting to the React workspace while checking the channel, request ID, message shape, and source revision.

The top-level page registers exactly ten WebMCP tools through document.modelContext. Inputs are runtime-validated, imported source and accessibility snippets are marked as untrusted content, stale revisions are rejected, and read-only tools use the appropriate annotations.

Most importantly, the agent cannot manufacture human approval. Contextual approval tokens are created only when the developer approves the exact visible proposal through the interface.

Challenges we ran into

The first major challenge was executing axe inside an opaque sandbox while safely returning useful results to the parent application. We needed enough communication for rendering, scanning, and highlighting without granting the preview same-origin access.

The second was reliable source mapping. Existing HTML IDs were not sufficient because imported documents can have missing or duplicate IDs. We instead built parser-backed mappings using exact source ranges and preview-only internal metadata.

The third was keeping proposals bound to the correct source revision. Rendering, scanning, agent calls, and human actions are asynchronous, so Curbcut rejects stale issue and proposal IDs and requires the exact proposed preview to report ready before Apply becomes valid.

Finally, we had to make the human-agent boundary technically enforceable. A prompt asking the agent to wait was not enough. The application itself had to reject unauthorized contextual changes and preserve the proposal and source unchanged.

Accomplishments that we're proud of

A real end-to-end WebMCP workflow where external browser-agent actions visibly update the same workspace the developer is reviewing
Real axe scans against an isolated live preview rather than stored or fixture-specific results
Exact mapping from rendered axe nodes to editable source without relying on user-provided IDs
Small deterministic patches instead of whole-document model rewrites
A visible, enforceable human-approval boundary for semantic changes
Fresh rescan verification, exact Undo, and clean export
Five bounded repair families, with color contrast intentionally kept as evidence rather than guessed automatically
An unrelated imported profile-form test proving that the scanner and mapping system are not hard-coded to the checkout demo
88 passing unit and integration tests and 30 passing browser tests
A 72-trajectory WebMCP evaluation with 69 operationally correct workflows, zero approval-boundary violations, and zero infrastructure failures
A production deployment exercised through browser-agent tooling with all ten tools discoverable and no WebMCP console errors

Curbcut does not claim automated WCAG compliance. A cleared automated finding proves only that the targeted automated check disappeared after a fresh scan. Manual review, assistive-technology testing, and disabled-user expertise remain essential.

What we learned

We learned that WebMCP is most valuable when it exposes meaningful product actions rather than generic browser control. The browser agent does not replace the application; it gains a structured way to participate in the application’s existing workflow.

We also learned that accessibility repair is as much an authority problem as a code-generation problem. Some changes are mechanical. Others require someone to decide what an image, label, or control means. A useful agent should understand and respect that distinction.

Finally, source mapping and safe execution boundaries were more challenging than generating the patches themselves. Making every action visible, reversible, revision-bound, and verifiable is what turned the idea into a coherent product.

What's next for Curbcut

Next, we would test Curbcut with more accessibility practitioners and frontend developers, improve the editing and diff experience, and carefully add more deterministic repair families where automation is defensible.

Longer term, the same shared-workspace model could support reviewed accessibility contributions across larger projects. The principle would remain the same: let the agent handle mechanics while the human retains authority over meaning.