Forem: Aethel Software

AccessFix Update!

Aethel Software — Mon, 03 Nov 2025 20:42:00 +0000

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

I Built an Accessibility Checker in a Week (Beta Launch - Feedback Wanted)

Aethel Software — Fri, 10 Oct 2025 12:19:27 +0000

The Problem I Was Trying to Solve

Accessibility always gets pushed to the end of the development cycle.

Not because developers don't care, but because:

Existing tools are hard to interpret (WCAG codes aren't beginner-friendly)
Checking takes time we don't have
Fixing issues manually is tedious
It's easy to forget until someone complains

So I built AccessFix — a free accessibility checker that scans your site and tells you exactly what to fix.

⚙️ What It Does (Beta Version)

Current Features

Paste your website URL (or upload HTML/code)
Scans for 15+ common accessibility issues
Shows you exactly where the problem is (line numbers)
Gives you the recommended fix
Displays code snippets with before/after examples

What It Checks

✅ Missing alt text on images

✅ Form inputs without labels

✅ Buttons without accessible text

✅ Links without text content

✅ Missing lang attribute on HTML

✅ Iframes without title attributes

✅ Tables missing header cells

✅ Heading hierarchy issues

✅ Empty alt attributes on meaningful images

✅ And more...

Each issue includes:

Severity level: critical / warning / info
WCAG criteria reference
Line number in your code
Recommended fix
Before/After code snippet

🧠 The Tech Stack

Frontend

React + Vite
TypeScript
Supabase (auth + database)

Backend

Supabase Edge Functions (Deno)
HTML parsing with regex (yep, it works for beta)
Custom scanning logic

Why I Chose This Stack

Fast to build
Supabase handles auth, database, and storage
Easy deployment on Vercel
No complex infrastructure

🚀 What's Coming Next (Post-Beta)

Phase 2: GitHub Integration

Connect your GitHub repo
Scan your entire codebase automatically
Track accessibility issues over time

Phase 3: AI-Powered Fixes

AI analyzes your code
Auto-generates pull requests with fixes
You review and merge

Phase 4: Continuous Monitoring

Schedule regular scans
Get notified of new issues
Track your accessibility score over time

🧩 The Challenges I Faced

1. Parsing HTML Is Harder Than I Thought

Started with simple regex… but HTML is chaos.

Nested tags, self-closing tags, inline styles — a mess.

Current version works for most cases, but a real parser is coming.

2. False Positives

Some images should have empty alt text (decorative).

Some buttons use aria-label instead of text.

Balancing accuracy vs. over-reporting is tricky.

3. Making It Actually Useful

Tools like Lighthouse, axe DevTools, and WAVE already exist.

My differentiator:

Simpler language (no cryptic WCAG codes)
Line-by-line fixes, not just “you have 10 issues”
Future: Auto-PR generation (nobody does this simply)

🖼️ Screenshots

Dashboard with scan input and output
Individual issue detail with code snippet
Severity breakdown

🧪 Try It Yourself

AccessFix (Beta): https://accessfix.vercel.app

It’s completely free — just create an account, paste your website URL or upload HTML to start scanning.

💬 I Need Your Feedback

This is a beta launch — it’s far from perfect.

I’d love your input on:

🐛 Bug reports: what broke?
⚠️ False positives: what was flagged incorrectly?
✨ Feature requests: what’s missing?
💭 Honest feedback: is this useful or redundant?

Specific Questions

Would you use this over Lighthouse/axe? Why or why not?
What would make the AI-powered PR generation valuable?
Should there be a paid tier for teams, or stay free?

🧠 Lessons Learned

What Worked

Shipping fast (2 days) instead of over-building
Using Supabase to skip backend boilerplate
Focusing on one pain point (a11y scanning)

What I’d Do Differently

Validate with 10+ devs before coding
Use a proper HTML parser from the start
Add better test coverage

💡 The Backstory (Why I Built This)

I’m a starting developer.

This is my third product attempt this year:

React component kit → 900 views, $0 sales
Web design guide → 25 views, $0 sales
Now this → ???

The first two failed because I built things nobody needed.

This time, I’m building with feedback first, not after.

If AccessFix helps even 10 developers make their sites more accessible, that’s a win.

🔮 What’s Next for Me

This Week

Fix bugs from beta feedback
Add GitHub integration
Start building AI-powered fixes

Long-Term

If AccessFix gains traction → scale into full product
If not → pivot, learn, and try again

I’m building in public.

Follow along if you want to see a teenager figure out how to ship products people actually use.

🔗 Links

🌐 Try AccessFix: https://accessfix.vercel.app
💻 GitHub: (add repo link if public)
🧭 Follow my journey: (Ko-fi / Twitter / wherever)
💼 Hire me for web dev: aethelsoftware@gmail.com

Thanks for reading. Now go make your websites more accessible 🚀

P.S. – If you find bugs, please be gentle. I’m learning as I go.

I've Built 3 Products with 0 Sales - Help Me Build Something People Actually Want

Aethel Software — Thu, 09 Oct 2025 13:00:00 +0000

I'm a teenage developer who's learned a hard lesson: blindly building SaaS people don't want is a waste of time.

So far I've built:

React component kit (0 sales)
Web design guide (0 sales)
A11y checker (not launched yet)

Before I spend more time building, I want to actually talk to potential customers.

If you're a developer or run an agency, I have one question:

What tool would make your life easier that you'd actually pay $5-10/month for?

I'll share results in a follow-up post. Thanks for helping a starting developer out how to build something useful 🙏

Would You Trust an AI to Fix Accessibility in Your Codebase?

Aethel Software — Tue, 07 Oct 2025 14:00:00 +0000

Accessibility (a11y) is one of those things every dev knows matters—until the deadline hits.

We add alt text later. We tweak color contrast later. We fix ARIA warnings later. And “later” either never comes, or it takes ages of torture to fix. 🤕

I’ve been experimenting with a dev tool idea called AccessFix—a GitHub-integrated service that automatically detects accessibility issues in your pull requests and creates a PR with the fixes already applied.

It’s like having an a11y engineer review every commit—without extra process overhead.

Before I build this into a real SaaS, I want to ask the community:

Would you trust AI-generated accessibility fixes?
What’s the most annoying part of making your app accessible today?
Would your team use this if it came as a GitHub App or CI plugin?

Curious to hear from anyone who’s had to juggle performance, deadlines, and accessibility at once, or just had to suffer through ages of checking mundane a11y errors.

Let’s make the web less broken. 🌐

I Built a React UI Component Kit to Save Time — Here’s What I Learned (and You Can Use It Too)

Aethel Software — Sun, 05 Oct 2025 19:33:14 +0000

Hey fellow developers,

I’ve been building a small React UI Component Kit to make my own projects faster — and it worked so well that I decided to share it!

Why I Built It (I was wasting so much time)

Every new project I started had the same frustrating initial steps:

Create a new repo.
Add a sidebar, navbar, modal, etc.
Style everything again.
Waste hours before actually developing my app.

To finally escape this loop, I bundled my favorite reusable pieces into one mini kit. The goal was simple: copy-paste and ship faster.

What’s Inside the Kit

This is a set of production-ready components designed to cover the essentials:

Navbar
Sidebar with icons
Modal
Clean folder structure
All components have both JSX and TSX versions

You can literally copy-paste a component and it just works.

Live Preview & Demo

Curious to see it in action?

🎥 Live Demo + Preview: Website Demo
📺 Short Preview Video: Video Demo

Want to Try It?

I put the full kit up on Payhip here: Get the Full React UI Kit on Payhip.
It’s priced low to help indie devs skip boilerplate and ship faster.

Lessons Learned While Building and Sharing

Packaging your own tools helps you code faster than anything else. I now reuse at least half of what I build across projects.
Tiny UI details = big perception difference. Rounded corners, subtle shadows, glass details, and consistent spacing matter more than we think.

What’s Next

I’m working on a free guide for beginners on web design basics — clean layout, fonts, colors, and accessibility.

Download the Free Web Design Guide

If you liked this or have any feedback, please drop a comment or a like — I’m learning as I go, and every bit of feedback helps!

(And if you’ve built your own component kits or small React tools, please share — I’d love to see them!)