PRGate
Sign in with GitHub READYAUDIT + REVIEW

ACCESSIBILITY REMEDIATION WORKSPACE

Fix access.
Keep the proof.

Audit a public preview, focus on barriers with the greatest user impact, and keep the evidence behind every result.

NEW AUDIT

Choose a public preview

SAFE BRANCH

PRGate can propose changes only in a disposable branch. It never writes to your main branch, and it opens a pull request only after fresh verification succeeds.

Start with a public preview URL, or try the live example for a guided walkthrough.

Before you run
  • Use a preview you own or are authorized to test.
  • The worker needs a publicly reachable URL.
  • Sign in to save team-owned audit work and schedules.

CURRENT STATUS

No audit selected

WAITING

Start an audit to create a findings queue and captured evidence.

  1. 01Baseline audit
  2. 02Visual review
  3. 03Patch proposal
  4. 04Fresh render
  5. 05Verification

LIVE EXAMPLE

See a real audit before connecting your own preview.

PRGate will scan an intentionally flawed public storefront through the same audit workflow used for any public preview.

RESULTS

Evidence and findings will appear here

Start an audit to create a prioritized queue and a durable browser-evidence record.

NO RUN YETSAFE BRANCH WORKFLOW

03 / RENDER EVIDENCE

Captured preview

WAITING
Baseline screenshots are stored with the run.

They provide the before-and-after record needed to support a verification decision.

04 / PRIORITIZED FINDINGS

Findings queue

00

Critical work and uncertain decisions rise to the top after the baseline is complete.

WAITING FOR RESULTS

Each finding will include its impact, WCAG reference, and the next safe action.

THE CLOSED LOOP

How verification works

Every stage leaves a record. A change is not called verified until a fresh rendered result supports it.

01

Baseline audit

Capture the rendered page, accessibility tree, and deterministic findings.

02

Visual review

Check the interface a person encounters for barriers automated rules may miss.

03

Patch proposal

Prepare the smallest source-level change in an isolated branch.

04

Fresh render

Render the changed preview after tests and deployment checks pass.

05

Verification

Keep a success claim only when fresh evidence supports the fix.

VERIFIED MEANS

Not “a patch was written.”
A fresh render supports the fix.

When evidence is inconclusive, PRGate should mark the issue for human review instead of turning uncertainty into a success claim.