PRGate

Inspiration

Accessibility tools are excellent at identifying issues, but they often leave teams with a long backlog and no proof that a proposed fix actually works for a real user. We wanted to close that gap.

PRGate was inspired by a simple question: what if an accessibility agent could inspect a rendered website, fix the underlying code safely, look at the deployed result again, and only claim success when it has evidence? The goal is not to replace accessibility experts, but to remove repetitive remediation work while keeping human review and proof at the center.

What it does

PRGate audits a live public preview for accessibility barriers, including issues found by axe-core and visual issues that static analysis can miss.

It then:

1. Captures browser screenshots and accessibility-tree evidence.
2. Prioritizes findings by user impact and WCAG relevance.
3. Proposes source-level fixes inside an isolated GitHub branch.
4. Runs the target repository’s tests.
5. Waits for a Vercel Preview Deployment.
6. Re-renders and re-audits the changed preview.
7. Stores before and after evidence for every result.
8. Opens a GitHub pull request only when all fixes in the batch verify.

If a fix cannot be proven after the allowed retry attempts, PRGate marks it for human review instead of pretending it is complete.

How we built it

We built the dashboard and API layer with Next.js, React, and TypeScript. Supabase provides GitHub OAuth, persistent run history, private screenshot evidence, and rate limiting.

Inngest orchestrates the durable audit, patch, preview, verification, daily rescan, and retention workflows. The browser worker runs in a Render Docker service with Playwright and axe-core, allowing the system to render real pages, capture screenshots, inspect accessibility information, and perform static audits.

For safe remediation, PRGate uses Vercel Sandbox to clone the target repository into an isolated environment, create a disposable accessagent/run-* branch, apply bounded edits, run tests, and push the branch. Vercel then creates a Preview Deployment that PRGate audits again before opening a pull request through the GitHub API.

Codex, using GPT-5.6 Terra during development, helped us implement, inspect, test, debug, and iterate on the system. The runtime uses the OpenAI Responses API through a structured provider interface for visual inspection, patch planning, and verification. Playwright remains responsible for browser control and evidence capture.

Challenges we ran into

The biggest challenge was making the system genuinely evidence-driven instead of producing a convincing but unverified demo.

Browser automation on serverless infrastructure was difficult because full Chromium runtimes have storage, memory, and execution constraints. We separated the public Vercel dashboard from the Render-based browser worker to give Playwright a reliable Docker environment.

We also encountered provider quotas, structured-output incompatibilities, sandbox patch failures, preview deployment timing, and Inngest endpoint synchronization conflicts. These failures shaped the product: patch edits are validated before application, tests run before preview verification, retries are bounded, and unsuccessful runs become human-review states.

Another important challenge was avoiding false positives. For axe-originated issues, fresh axe results are authoritative after a re-render. For visual barriers, PRGate compares screenshots, accessibility context, and the original finding before calling a fix verified.

Accomplishments that we're proud of

We are proud that PRGate completes a real closed loop instead of stopping at a report or generated diff.

The system successfully:

• Audits a rendered target through Playwright and axe-core.
• Captures stored before and after browser evidence.
• Detects real missing image alternatives, unlabeled form controls, and contrast issues.
• Creates isolated source changes in temporary GitHub branches.
• Runs repository tests before deployment.
• Waits for and audits a real Vercel Preview Deployment.
• Verifies fixes using fresh browser-derived evidence.
• Creates a GitHub pull request only after all fixes verify.
• Keeps failed or inconclusive fixes out of the verified path.
• Supports scheduled daily rescans and evidence retention cleanup.

We are also proud that the dashboard is designed around the same accessibility principles it evaluates: high contrast, clear states, visible evidence, keyboard-accessible controls, and no fabricated findings before a real audit occurs.

What we learned

We learned that autonomous coding is most valuable when it is paired with strict verification, not when it simply produces more code.

A source diff does not prove that an accessibility issue is resolved. The deployed page may behave differently, a style change may create a regression, or an AI-generated edit may not apply cleanly. Real browser evidence, tests, isolated branches, and preview deployments make the system more trustworthy.

We also learned that deployment architecture matters as much as prompts. Separating the lightweight dashboard from the browser-capable worker made the system more reliable and made its security boundaries clearer. Finally, we learned to treat model quotas and provider failures as normal operational states that need explicit retries, limits, and human-review paths.

What's next for Access Agent

Next, we want to expand keyboard-navigation and focus-management testing, improve source-file mapping for complex repositories, add team-level review workflows, and make the remediation policy more configurable.

We also plan to add richer issue explanations for developers and accessibility consultants, stronger regression detection across multiple pages, configurable model tiers, cost controls, and deeper GitHub PR summaries.

Long term, PRGate can become a continuous accessibility reliability layer: not just finding issues, but continuously proving that fixes remain valid as websites evolve.

Built With

• axe-core
• codex
• docker
• github
• gpt-5.6-terra
• inngest
• next.js
• octokit
• openai-responses-api
• playwright
• react
• render
• supabase
• typescript
• vercel
• vercel-sandbox
• zod