AccessFix AI 以本地 AI 輔助檢測及修復網站無障礙問題

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I Built

What if your website is haunted, but you can't see the ghosts? 👻

Imagine building a beautiful website. Everything looks polished. The buttons work, the layout feels perfect, and the design looks production-ready.

But something is hiding underneath.

A button has no accessible name. A form field has no associated label. Text blends into its background, making it difficult to read.

For developers, these problems can be nearly invisible. For people who rely on assistive technologies, they can become real barriers.

That's what inspired me to build AccessFix AI — an open-source, local-first AI agent that detects, explains, safely repairs, and verifies web accessibility issues.

For Hacktoberfest's Ghost in the Machine theme, I gave those invisible barriers an identity.

Meet Ghost Mode. 🎃

Instead of simply presenting a list of accessibility errors, AccessFix AI turns them into ghosts haunting your website.

Each ghost represents a genuine issue detected by an accessibility scanner.

The goal isn't just to discover these ghosts. It's to safely exorcise them and prove they're gone.

What AccessFix AI does

1. Scans a website: Uses Playwright and axe-core to discover accessibility violations.
2. Explains the problems: Displays affected elements, rule IDs, and relevant issue details.
3. Generates AI-powered fixes: Runs an open-weight coding model locally through Ollama.
4. Reviews proposed changes: Shows the original and AI-generated code side by side.
5. Enforces safety: Validates proposed modifications with a strict AST-based security gate.
6. Requires human approval: Never applies the generated fix without permission.
7. Applies and verifies: Uses real browser-based accessibility testing to check whether the fix worked.
8. Supports rollback and reset: Restores the original demo when needed.

Ghost Mode: Making invisible barriers visible

Ghost Mode introduces five meaningful states:

These aren't fictional results added for Halloween.

Every status is derived from actual scanning or verification data.

The ghosts may be a metaphor, but the accessibility problems are real.

Demo

The most exciting part of this project was watching AccessFix AI successfully repair a real accessibility issue.

Rather than showing a hardcoded demonstration, I tested the complete workflow using my local AI model and an actual Chromium browser.

The experiment

My intentionally inaccessible demo initially contained:

• button-name — A button without an accessible name.
• color-contrast — Text with insufficient contrast.
• label — A form field missing an associated label.

The baseline scan discovered 3 violated accessibility rules affecting 4 elements.

I then asked AccessFix AI to generate a repair using the locally running qwen2.5-coder:1.5b model.

The AI-generated fix

The model identified the helper-text color as a candidate for improvement and selected this change:

- color: '#a3a8b5'
+ color: '#000000'

But generating code wasn't enough.

Before applying the change, AccessFix AI checked it against the restricted AST safety policy.

The modification passed validation, I explicitly approved it, and the application applied the proposed fix.

Then Playwright and axe-core scanned the updated website.

The actual results

One real accessibility rule resolved. Zero new rules introduced.

That's a 33% reduction in violated rule types in this specific demonstration—not a claim that the entire website is now 33% more accessible.

The remaining issues were still reported honestly.

After verification, I reset the application and scanned again. The original 3 rules affecting 4 elements returned, confirming that the reset restored the original demo.

Both demo files also matched their starting contents after the workflow.

Watch the demo

🎥 Demo video: [https://youtu.be/tjIB_Y66GS0]

The approximately 110-second walkthrough covers:

• Discovering accessibility ghosts
• Generating a fix with local AI
• Reviewing the proposed code
• Explicitly approving the modification
• Applying and verifying the fix
• Viewing the updated Ghost Mode results
• Resetting the demo

AccessFix AI currently runs as a local prototype, so the video and repository instructions demonstrate its functionality without requiring a public hosted AI service.

Code

🔗 GitHub repository: [https://github.com/kanwar05/AccessFix-AI.git]

The project includes the application source code, installation instructions, architecture documentation, tests, and verification evidence.

It is released under the MIT License, with separate notices for the model and third-party dependencies.

Run it locally

AccessFix AI uses Ollama for local model inference.

First, install Ollama and download the coding model:

ollama pull qwen2.5-coder:1.5b

Then clone the repository and follow the README to install dependencies and launch the application.

The repository also documents the Playwright browser requirements and the development configuration.

The AI model can run locally after its initial download, without sending source code to a proprietary hosted model API.

How I Built It

I wanted AccessFix AI to be more than another application that asks an LLM to generate code.

My main engineering question was:

How can we let AI fix code without blindly trusting everything it generates?

My answer was to separate AI reasoning from permission to modify source code.

Technology stack

Architecture

        React Frontend
              |
              v
     Accessibility Scan
       Playwright + axe
              |
              v
     Accessibility Report
              |
              v
       Local Ollama AI
      Qwen2.5-Coder 1.5B
              |
              v
       Proposed Code Fix
              |
              v
      Code Comparison UI
              |
              v
      Explicit User Approval
              |
              v
       AST Safety Gate
          /       \
      Reject      Accept
                    |
                    v
              Apply Fix
                    |
                    v
         Playwright + axe
             Verification
                    |
                    v
          Before/After Report
                    |
                    v
           Reset or Rollback

The hardest challenge: Making AI-generated edits safe

Initially, my local model generated valid JSX that looked reasonable, but it also changed visible component content outside the application's approved modification policy.

The AST security gate rejected it with:

UNSUPPORTED_PROPOSED_CHANGE

That was an important moment.

The application had done exactly what its safety architecture was supposed to do: reject an AI-generated modification it could not safely authorize.

Rather than weakening the gate to make the demo pass, I improved the generation workflow so the model could produce more targeted, supported changes.

The successful experiment used the model-selected helper-text color modification while preserving the restricted AST policy.

The application also includes rollback handling, stale-proposal protection, duplicate-request protection, and explicit approval requirements.

The AI proposes.

The safety gate validates.

The developer approves.

The browser verifies.

No single component is blindly trusted.

Testing and validation

My final reported validation results were:

• 74 backend tests passing
• 2 Ghost Mode tests passing
• 76 tests passing in total
• ESLint passing
• Production build passing
• Genuine Ollama generation verified
• Real Playwright and axe verification completed
• Reset behavior verified
• Unsafe proposal rejection and rollback tested

The implementation and verification details are documented in the repository.

Why Does Open Innovation Matter?

For me, open innovation is not simply about publishing code.

It is about building software that developers can inspect, modify, and operate on their own terms.

AccessFix AI is designed around that principle.

1. Your source code stays under your control

Many AI-assisted development tools send source code to externally hosted inference services.

AccessFix AI uses a locally running open-weight model through Ollama.

Developers can perform AI inference on their own machines instead of submitting the relevant code to a third-party AI API.

For a tool that examines and proposes modifications to source code, that control matters.

2. No usage-based cloud AI charges

Once the required model and dependencies are available, local inference doesn't incur per-request charges from a hosted model provider.

There are still hardware, electricity, and maintenance costs, but developers are not forced into a metered AI API to run the core functionality.

3. The model isn't the source of truth

An LLM can produce syntactically valid but unsafe modifications.

AccessFix AI treats the model as a proposal generator—not an authority.

The AST safety gate restricts what can change, and Playwright plus axe-core provide independent evidence about the effect of a permitted modification.

This separation is especially important when working with generated code.

4. Developers can inspect and extend the system

Because the application uses open tooling and an open-weight model, developers can investigate the implementation, examine the safety rules, and adapt the workflow for their own needs.

They're not dependent on a single proprietary inference endpoint.

5. Accessibility should be approachable

Accessibility testing can feel overwhelming, especially when developers receive a long report without knowing what to fix first.

I wanted to combine the reliability of established accessibility tools with the explanatory and code-generation capabilities of local AI.

Open innovation made it possible to bring those pieces together.

Open-weight AI provides the intelligence. Open-source tools provide the evidence. The developer remains in control.

My Agent Session

AI coding assistance was part of my development workflow, alongside iterative implementation, testing, debugging, and manual review.

One of the most interesting engineering challenges was refining the AI proposal workflow without weakening the AST safety gate.

The development process included unsuccessful proposals, policy rejections, additional regression tests, and finally a verified repair.

That progression is an important part of the project: successful AI engineering involves validating the output, not merely accepting it.

The Spirit of It 👻

What started as a Halloween interpretation became a reminder of a real software engineering problem.

A website can appear perfectly functional to one person while containing serious barriers for someone else.

Those barriers are invisible until we know how to look for them.

The moment that made AccessFix AI feel real wasn't when the AI generated a piece of code.

It was when the browser verification confirmed:

Before: 3 violated rules
After:  2 violated rules

Resolved:   color-contrast
Remaining:  button-name, label
Introduced: none

Result: Verified improvement

And after resetting:

Original baseline restored
3 rules / 4 affected elements

The repair was real, measurable, and reversible.

That's the kind of AI-powered developer tooling I want to build: systems that don't simply produce impressive answers, but can demonstrate that their actions made something better.

Of course, automated testing cannot detect every accessibility problem, and one resolved rule doesn't make a website fully accessible. Human testing and broader accessibility review remain essential.

But even a small verified improvement matters.

This Halloween, I didn't build a chatbot to tell ghost stories.

I built an AI tool to discover the ghosts hiding inside our websites—and help developers safely remove them.

Happy Hacktoberfest! 🎃

Hacktoberfest #OpenSource #Accessibility #AI