Safari Browser - Not supported
OpenAI Browser - Standard Supported
OpenAI Browser - Standard Supported - Dark Mode
Homepage
Homepage - Dark Mode

easyACR

Inspiration

An Accessibility Conformance Report, or ACR, explains how well a digital product supports recognized accessibility requirements such as WCAG. It gives customers, procurement teams, accessibility professionals, and product owners a structured way to understand what a product supports, where barriers remain, and what evidence supports each claim.

An ACR is commonly produced by completing a Voluntary Product Accessibility Template, or VPAT. The VPAT provides the reporting structure and specifications that when completed produces an ACR. Producing a useful ACR requires more than just filing in this template. Teams must evaluate the product, collect evidence, interpret criteria, describe limitations, and keep updating the document as the software changes.

The idea for easyACR grew directly from my experience as an accessibility officer at a software firm. In that role, I see the importance of trustworthy accessibility documentation and the amount of specialized, repetitive work required to create it. Evidence is distributed across scans, manual testing, bug trackers, product docs, and conversations with engineers. Turning that information into a clear report is difficult for teams that do not have dedicated accessibility resources.

This matters to us because accessibility is part of delivering responsible software. People rely on digital products to access information and services and customers need accurate conformance information to make purchasing and deployment decisions. An ACR can guide remediation, improve accountability, and help teams make better decisions.

easyACR has evolved into a focused service that combines automation, agent assistance, and human judgment. Its purpose is not to replace accessibility audits and professionals or claim that an automated scan means conformance. It is to spend less time gathering and organizing evidence and more time understanding barriers and improving the product.

What it does

easyACR is an accessibility service that scans authorized public websites and turns automated findings into a structured draft ACR based on the VPAT standard.

A person can use the accessible React interface to start a scan, follow progress, inspect findings, and create draft evidence aligned with WCAG 2.2. An assisting agent can perform the same workflow through four WebMCP tools:

start_accessibility_scan
get-scan-status
list_accessibility_issues
create_draft_acr

This is a strong WebMCP use case because an accessibility review is a structured, multi-step process rather than a single prompt or button. The agent needs to start an authorized job, monitor asynchronous progress, retrieve trustworthy results, and prepare evidence without exceeding the person’s permissions or the service’s security.

WebMCP creates a better experience by giving people more than one way to interact. Someone can use the visible interface, work through an agent, or move between both approaches. The browser and agent paths reach the same application functions, permissions, job state, and evidence. This provides choice without creating two different products.

Together, a person can define the goal, authorize the target, and provide judgment while an agent handles repetitive coordination: starting the scan, checking its status, gathering relevant findings, and organizing draft evidence. Previously, that work often required manually transferring information among scanners, reports, spreadsheets, and AI conversations. easyACR makes it one continuous and inspectable workflow while keeping the final certification manual.

How we built it

The browser experience uses React 19, TypeScript, and Vite. We built the interface around semantic structure, keyboard operation, visible focus, contrast, reflow, and clear messaging making accessibility part of the product foundation rather than an afterthought.

WebMCP is implemented with the browser-native document.modelContext.registerTool() API. Each of the four tools has a JSON input schema, returns structured results, and observes the abort-signal lifecycle for cleanup. The callbacks use the same shared application services as the visible React controls and call the same authenticated Node.js API, so rules and results remain consistent across human and agent interactions.

The rest of the stack includes:

A Node.js API service for sessions, authorization, terms acceptance, CSRF protection, quotas, jobs, findings, and evidence.
Playwright and Axe for automated accessibility scans.
Supabase Auth, Postgres, and row-level security for identity and durable jobs, findings, and evidence.
Resend SMTP for magic-link authentication emails.
Private authentication and data gateways that keep privileged credentials away from the browser and scanner.
An authenticated scanner egress proxy that blocks private networks, unsafe redirects, and unauthorized destinations.
pnpm, Vitest, Playwright route tests, and automated accessibility checks.
Docker Compose and Caddy on a Hetzner Cloud VPS, with Caddy providing the public HTTPS edge.

Challenges we ran into

The largest challenge was making the agent path as trustworthy as the visible interface. Registering a browser tool is straightforward; ensuring that every invocation respects authentication, accepted terms, authorization, quotas, cancellation, and evidence boundaries is more difficult.

WebMCP is an emerging browser capability, we had to work through registration behavior, feature detection, browser compatibility, schemas, cleanup, and useful messaging. The prototype’s four tools now work, but getting there required separating browser integration problems from API, session, and local-environment problems.

The scanner introduced a second security challenge. A service that opens user-provided URLs can become an unintended gateway into private networks. We addressed this by scoping to public HTTPS-only targets, same-origin crawling, a ten-page limit, redirect checks, private-address blocking, isolating Playwright workers and an egress proxy.

Additionally, automated tools can identify valuable evidence, but automated results are not an accessibility certification. The interface, tool descriptions, and generated evidence consistently reinforce that qualified human review remains necessary.

Accomplishments that we're proud of

We are proud that easyACR treats accessibility as both the purpose of the service and a requirement of its own interface.

All four WebMCP functions work through the current browser-native registration pattern. They expose a meaningful end-to-end workflow rather than isolated demonstrations, and they share behavior with the interface instead of duplicating business logic.

Most importantly, the product maintains an honest division of responsibility: automation gathers and organizes evidence, agents help coordinate the work, and people remain responsible for interpretation and accessibility decisions.

What we learned

We learned that agent accessibility is not only about letting an AI operate a website. It is about offering equivalent ways to act while preserving the same context, safeguards, and outcomes.

WebMCP works best when tools map to clear user intentions rather than low-level interface actions. “Start an authorized accessibility scan” is more useful and reliable than asking an agent to imitate a series of clicks. Structured inputs and results also make the workflow easier to inspect, test, and recover when something fails.

We validated our thoughts that the shared application functions are essential. When the interface and WebMCP callbacks use the same service layer, improvements to validation, security, and business rules benefit both paths.

What's next for easyACR

Next, we plan to strengthen the path from automated findings to collaborative human review. That includes richer evidence workflows, clearer remediation guidance, improved progress and error reporting, and more ways for reviewers to add context that automation cannot observe.

We also want to improve recovery for interrupted or long-running scans, and continue refining the tool schemas based on real life workflows.

On the infrastructure side, the next steps include selecting a CI service, automating repeatable verification and deployment, and adding a preview environment before production releases. We will continue hardening the scanner boundary, data retention controls, monitoring, and operational documentation as the service grows.

The technology will keep evolving, but the purpose will remain constant: combine accessible design, responsible automation, and human judgment to help create a better web for everyone.