AccessPatch

Find it. Repair it. Prove it. Prevent it from returning.

Comment

Inspiration

I believe many more digital projects should have a practical path to improving accessibility. Smaller development teams in particular need support that makes concrete barriers easier to identify, repair, and verify without pretending that automation can replace expert human review.

I see AccessPatch not as a complete solution, but as a deliberately limited first step toward making more digital experiences usable by more people.

Accessibility problems are often presented as isolated checklist findings. Real users, however, experience them as broken journeys: a form field cannot be understood, keyboard focus becomes invisible, or a critical action becomes difficult to complete.

AccessPatch explores a more accountable workflow: reproduce the actual journey, collect evidence, create a bounded repair plan, apply controlled fixes in isolation, replay the same journey, and preserve proof of what changed.

What it does

AccessPatch is a Journey Repair and Proof Agent for React and TypeScript applications.

The current controlled demonstration uses one multi-step checkout journey and two intentional accessibility barriers:

  • an email field with visible text but no programmatically associated accessible name;
  • a primary action that receives keyboard focus but has no visible focus indicator.

AccessPatch:

  1. runs the checkout journey using the keyboard;
  2. records accessibility and browser evidence at the relevant journey states;
  3. normalizes the two findings;
  4. sends bounded evidence to GPT-5.6 for a structured repair plan;
  5. validates the suggested strategies against an allowlist;
  6. applies deterministic repair templates in a disposable copy;
  7. replays the same journey;
  8. verifies the accessibility and functional result;
  9. generates a Proof Bundle for review.

After repair, the same checkout journey reaches confirmation, Axe reports zero violations for the controlled replay, and the primary action has a visible solid three-pixel focus outline. The original fixture remains unchanged.

The Proof Bundle connects the findings, repair plan, exact source diff, replay result, audit records, WCAG mappings, and remaining human-review requirements.

AccessPatch also includes a controlled Mutation Guard demonstration. It injects one known ARIA-hidden focusable regression into another disposable copy, detects it exactly once, confirms that the original fixture is unchanged, and cleans up the temporary runtime.

How it was built

AccessPatch was built as a local, reproducible TypeScript workspace using:

  • React and Vite for the controlled checkout application;
  • Node.js and TypeScript for orchestration and evidence processing;
  • Playwright for keyboard journeys, replay, and browser evidence;
  • axe-playwright for automated accessibility checks;
  • the OpenAI Responses API with GPT-5.6 for bounded evidence-based repair planning;
  • deterministic templates for controlled source repairs;
  • pnpm for workspace and dependency management;
  • Git and GitHub for reviewed, traceable development.

The model does not directly write or apply source code. One bounded GPT-5.6 product call reviewed structured evidence with store: false and selected two allowlisted repair strategies. Those strategies were validated before deterministic templates performed the repairs in an isolated disposable copy.

How Codex was used

Codex was the primary engineering environment under human coordination.

It implemented most of the repository structure, application code, journey tooling, evidence processing, deterministic repairs, tests, security hardening, documentation, and reproducibility work.

Human review gates controlled the scope, product direction, claims, feature decisions, repository publication model, video, and final submission material. Codex suggestions were reviewed before acceptance, and important work was connected to commits, tests, and evidence records.

The completed project passed:

  • 178 API-free tests;
  • an eight-stage Judge Workflow;
  • a seventeen-stage clean-clone verification.

How GPT-5.6 was used

GPT-5.6 was used once in the product workflow through the OpenAI Responses API with store: false.

The model received bounded, structured evidence from the controlled checkout journey and produced a structured repair plan. It selected two supported strategies: associating the visible email label with its input and restoring a visible keyboard focus indicator.

The model output was not applied directly to source code. AccessPatch first validated the response against a schema and an allowlist. Deterministic repair templates then applied the approved changes in a disposable isolated copy before the same journey was replayed and verified.

No additional model call is required for judges to run the documented verification workflow.

Challenges encountered

A major challenge was keeping the project technically useful without overstating what automated accessibility tooling can prove.

It would have been easier to build a broad scanner or claim automatic compliance. Instead, AccessPatch was deliberately narrowed to one controlled journey, two reproducible barriers, bounded repair strategies, deterministic application, and explicit human-review boundaries.

Another challenge was separating model reasoning from code modification. GPT-5.6 contributes a structured repair plan, but its output is never applied directly. The plan must pass schema validation and match an allowed strategy before deterministic repair logic can act.

Reproducibility was also important. The repaired journey had to work from a clean clone, preserve the original fixture, generate reviewable evidence, and clean up temporary working data.

Accomplishments

I am particularly proud that AccessPatch demonstrates a complete and verifiable loop rather than stopping at detection:

Find it. Repair it. Prove it. Prevent it from returning.

The project connects a real keyboard journey to exact findings, a bounded GPT-5.6 plan, deterministic source changes, replay evidence, WCAG mappings, and clear manual-review requirements.

It also keeps the original fixture unchanged and provides a Judge Workflow that can be executed without making another model call.

What I learned

The project reinforced that responsible AI-assisted development depends as much on boundaries and verification as on model capability.

A useful model response is not the same as a safe code change. Structured schemas, allowlisted strategies, deterministic implementation, isolated execution, replay testing, and human review are all necessary parts of the workflow.

I also learned that accessibility evidence becomes more meaningful when it is connected to an actual user journey rather than reported only as an abstract score.

What’s next

AccessPatch is currently a controlled demonstration, not a general-purpose accessibility platform.

Future work could carefully expand the number of supported repair classes and journey patterns while preserving the same evidence, isolation, replay, and human-review principles.

Possible next steps include:

  • additional controlled form and navigation barriers;
  • broader journey definitions;
  • stronger developer-facing review tools;
  • integration into pull-request workflows;
  • additional browsers and platforms;
  • evaluation with accessibility specialists and users with disabilities.

Any expansion should remain honest about what automation can detect, repair, and verify.

Limitations

AccessPatch currently supports one supplied React and TypeScript checkout fixture, one controlled keyboard journey, two repair classes, Chromium, and one controlled Mutation Guard scenario.

It does not currently support arbitrary repositories, complete accessibility testing, WCAG certification, legal compliance verification, BFSG or EAA assurance, or automatic production deployment.

Automated results are evidence for review, not proof that an application is fully accessible. Expert human accessibility review and testing with people with disabilities remain essential.

Built With

Share this project:

Updates