A month or so ago, I deployed my accessibility checker tool.
I was proud. It was a real project that I managed to deploy and make it work. It scanned websites for accessibility issues and showed you how to fix them.
The response? Decent but fair.
"This already exists. Use axe DevTools."
"Why would anyone use this when Lighthouse is better?"
"You're using regex to parse code? Really?"
I'd built something nobody needed, using the wrong approach, solving a problem that was already solved.
But instead of giving up, I took the feedback seriously.
What I Built (Version 1)
AccessFix started as a simple web app:
- Paste your website link or upload an html file
- Get a list of accessibility issues
- See recommended fixes
Sounds useful, right?
The problems:
- Just another web app - Developers scan paste this as "too simple"
- Didn't fit into workflows - No CI/CD integration, no automation
- Competed with established tools - Lighthouse, axe DevTools, WAVE all do this better
The Feedback That Changed Everything
One comment in particular stuck with me:
"This is useful if it slots into CI and comments on PRs with clear, fixable notes. Skip regex and run axe-core in a headless browser. Nail CI/PR annotations, real DOM scanning, and noise control, and folks will actually use this."
That comment became my roadmap.
The Rebuild (Version 2)
I spent the next month rebuilding from scratch.
What Changed
1. GitHub Integration (The Big One)
Instead of pasting code into a web app, you now can:
- Connect your GitHub account
- Select a repository
- Scan entire projects automatically
2. Axe-Core Scanning Integration
Instead of basic scanning with regex parsing, AccessFix now uses axe-core. This lets AccessFix keep up with all of the a11y issues, and identify more errors and warnings within your app.
3. Scoring System
5 errors may seem little, but sometimes they are very important. This scoring system now gives you an idea of how good/bad your app is accessibility wise.
The Tech Stack
Here's what I used to rebuild:
Frontend:
- React + TypeScript + Vite
- TailwindCSS for styling
Backend:
- Supabase (auth, database, edge functions)
- GitHub OAuth for authentication
- GitHub API for repo access
Scanning Engine:
- Axe-core
- jsdom (for HTML parsing)
- Custom logic for file-level scanning
Deployment:
- Vercel (frontend)
- Supabase Edge Functions (backend logic)
The Hardest Parts
1. GitHub OAuth Flow
Getting GitHub authentication working with Supabase was trickier than expected. The redirect flow broke multiple times during development.
Solution: Supabase has built-in GitHub OAuth, but you need to configure callbacks correctly in both GitHub App settings AND Supabase dashboard.
2. Scanning Entire Repositories
Fetching every file from a repo, parsing them correctly, and scanning for issues without hitting rate limits was complex.
Solution:
- Batch file fetching
- Only scan frontend files (.js, .jsx, .ts, .tsx, .html, .css)
- Cache results per commit hash
- Use GitHub API efficiently
3. False Positives
Early versions flagged EVERYTHING. Decorative images with empty alt text? Flagged. Hidden elements? Flagged.
Solution: Added context awareness:
- Check if elements are hidden (display: none, visibility: hidden)
- Understand decorative vs. meaningful images
- Parse ARIA attributes correctly
What I Learned About Building Products
1. Build in Public
Posting on Reddit was scary enough. Getting the lackadaisical response was pretty bad too.
But that feedback saved me MONTHS of building the wrong thing.
If I'd kept building in isolation, I'd still be working on a useless regex-based checker.
2. Developers Are Honest (Brutally)
Non-technical users will say "this is cool!" to be nice.
Developers will tell you exactly what's wrong. Use that.
3. Copy Good Ideas, Then Add Your Spin
I'm not competing with Lighthouse or axe DevTools.
I'm using axe-core (which powers those tools) and adding GitHub-native integration and AI-powered fixes.
Stand on the shoulders of giants.
5. Early Users Are Gold
I have 5 beta users now. FIVE.
A couple of them have offered me very good feedback.
That feedback is worth more than 1000 silent users.
Current State
What works:
- GitHub OAuth login
- Repository selection and scanning
- File-by-file analysis
- Issue dashboard with severity levels
What's coming:
- PR generation
- AI-powered fix suggestions
- Accessibility score tracking over time
- Team collaboration features
Try it: accessfix.vercel.app
Lessons for Other Builders
If you're building something and wondering if it's worth it:
1. Ship fast, get feedback faster
Don't spend 6 months building in secret. Ship an MVP in 2 weeks and let users tell you what's wrong.
2. Listen to harsh feedback
The comments that hurt the most are usually the most valuable.
3. Don't build in a vacuum
Talk to potential users BEFORE building. I learned this the hard way.
4. It's okay to start over
I could've tried to patch version 1. Instead, I rebuilt from scratch with the right approach. Best decision I made.
5. Integration > Standalone
Developers don't want another tool to learn. They want tools that fit into what they already use.
What's Next
Short term:
- Polish the UI
- Add PR commenting
- Get to 50 beta users
- Fix bugs as they're reported
Long term:
- AI-powered fixes that understand your codebase
- CI/CD integrations (GitHub Actions, GitLab CI)
- Team features (shared dashboards, role-based access)
- Premium tier for larger teams
The goal: Make accessibility checks as automatic as linting or testing.
Try It (And Break It)
AccessFix is live in beta: accessfix.vercel.app
If you:
- Build web apps
- Use GitHub
- Care about accessibility (or need to for compliance)
I'd love for you to try it and tell me what breaks.
Email bugs/feedback to: aethelsoftware@gmail.com
Top comments (0)