Access Forge

AccessForge turns accessibility findings into verified, developer-ready repairs—without modifying the original repository.

Comment

Inspiration

Accessibility testing often stops at a list of warnings. Developers still have to locate the responsible code, understand the problem, choose a safe repair, verify it, and prepare something that can be reviewed or merged.

I built AccessForge to close that gap. Instead of acting like another generic accessibility scanner, AccessForge transforms accessibility findings into bounded, explainable, and independently verified source-code repairs.

The main principle behind AccessForge is:

AI may propose a repair, but deterministic checks must decide whether it passes.

What it does

AccessForge accepts a project through:

  • An included judge-ready React sample
  • A public GitHub repository using read-only access
  • A locally uploaded ZIP archive

The user describes an important journey, such as:

Open checkout, enter an email, activate Pay now using only the keyboard, and confirm submission.

AccessForge compiles that description into editable steps and scans the supplied React or HTML source for accessibility barriers.

Every finding contains:

  • The affected file and line number
  • The detected source-code excerpt
  • Severity and WCAG criterion
  • A plain-language explanation
  • Bounded repair guidance

GPT-5.6 then receives the reproduced evidence and generates a structured repair plan. AccessForge applies supported transformations only to an isolated copy of the project.

The repaired files are sent to a separate verification endpoint, which independently reruns the deterministic accessibility rules.

When verification passes, users can download:

  • A reviewable source patch
  • A repaired project ZIP
  • A structured evidence report

The original GitHub repository is never modified.

How I built it

AccessForge is built with:

  • React 19
  • TypeScript
  • A Next-compatible Vinext runtime
  • OpenAI Responses API
  • GPT-5.6
  • Structured Outputs with Zod
  • JSZip
  • Deterministic JavaScript analysis and repair rules

The system contains four main services:

  1. Project intake loads bounded source files and detects the framework, package manager, and build configuration.
  2. Audit engine runs deterministic accessibility rules across multiple source files.
  3. Repair engine combines a structured GPT-5.6 plan with controlled source transformations.
  4. Verification engine independently reruns the rules against the patched files.

GPT-5.6 is used as a constrained accessibility repair planner. It receives only the user journey, reproduced findings, and relevant bounded source files.

Its response must match a strict schema containing:

  • A repair summary
  • A bounded risk classification
  • One change for each finding
  • A deterministic verification requirement

The model does not decide whether its repair is correct. The independent verification engine makes the final pass-or-fail decision.

If GPT-5.6 or the network is unavailable, AccessForge clearly enters deterministic fallback mode instead of crashing or pretending that a live model response succeeded.

Codex was used throughout development to shape the architecture, implement the interface and APIs, build the multi-file audit engine, create controlled repairs, write regression tests, diagnose failures, and prepare the working deployment.

Challenges I faced

Maintaining trust

The biggest challenge was preventing the interface from claiming more than the system had actually proved.

The current version performs static source analysis. It therefore does not claim to capture real browser screenshots, replay a live DOM journey, or provide complete WCAG certification.

The interface clearly communicates these boundaries.

Handling untrusted projects safely

Executing arbitrary repositories would introduce significant security and reliability risks.

I created a read-only intake pipeline with limits for:

  • File count
  • Individual file size
  • Total project size
  • Supported source types
  • GitHub URL format
  • ZIP archive contents

Dependencies, generated files, and build-output directories are ignored. Public GitHub intake never requests repository write permission.

Preventing fabricated evidence

A client could theoretically submit an invented finding to the repair endpoint.

AccessForge protects against this by reproducing every requested finding directly from the supplied source before allowing a repair. Findings that cannot be reproduced are rejected.

Separating generation from verification

Initially, repair and verification happened during the same operation.

I redesigned the system so verification is an independent request. It receives the original project boundary and patched files, reruns deterministic rules, and rejects changes that escape the supplied project.

Building a reliable interface

A progress-animation bug caused the final Evidence report created step to remain queued even after an audit had completed.

The problem was traced to a timer changing progress from 100% back to 92% during the completion transition. Fixing this reinforced an important lesson: a trustworthy developer tool needs reliable state management as much as it needs a strong AI system.

What I learned

I learned that responsible AI developer tools need clearly defined authority boundaries.

Language models are valuable for understanding evidence, explaining accessibility problems, and proposing context-aware repairs. However, verification should come from reproducible checks rather than model confidence.

I also learned that an honest and focused system is more valuable than a broad prototype that makes unsupported claims.

AccessForge clearly separates:

  • Static source evidence
  • GPT-5.6 repair planning
  • Controlled source transformation
  • Independent deterministic verification

Accomplishments

I am proud that AccessForge:

  • Provides a complete audit-to-repair workflow
  • Supports an included sample, public GitHub repositories, and ZIP uploads
  • Detects React, Next.js, Vite, and static HTML projects
  • Produces exact file-and-line evidence
  • Integrates GPT-5.6 structured repair planning
  • Applies repairs only to an isolated project copy
  • Independently verifies patched source
  • Rejects forged or unreproducible findings
  • Exports patches, repaired ZIP files, and evidence reports
  • Provides a responsive and keyboard-accessible interface
  • Passes lint, production builds, regression tests, and end-to-end API checks

What is next

The next phase is a secure browser runner that can:

  1. Install approved dependencies inside an isolated environment.
  2. Start the target application safely.
  3. Replay the compiled user journey.
  4. Capture DOM and screenshot evidence.
  5. Compare behavior before and after repair.
  6. Verify keyboard navigation and focus behavior at runtime.

After the read-only pipeline and browser runner are proven, AccessForge could add explicitly authorized GitHub pull-request creation, CI integration, team review workflows, and human accessibility-expert approval.

AccessForge is not intended to replace accessibility specialists. It is designed to give developers a safer and faster path from finding to evidence, repair, and verification.

Built With

Share this project:

Updates