Added Supabase. Added auto-scanning. Parsed my first real Android UI tree. It scored D.
Day 2 of AccessBuild. I've been on this chair for hours.
What I Built Today
Yesterday, AccessBuild could only score elements you pasted in manually. Today, it can scan a real Android app.
The new /scan endpoint accepts a raw Android UI tree XML dump. It parses every node, identifies interactive elements, extracts accessibility labels, and scores the screen automatically. Then it saves the result to Supabase.
No more manual data entry. Real apps. Real screens. Real scores.
The Stack Grew Up
| Day 1 | Day 2 |
|---|---|
| FastAPI | FastAPI |
| In-memory only | Supabase database |
| Manual element list | Android UI tree XML |
| One-off test | Persistent, repeatable audits |
| No history |
/audits/recent endpoint |
| No stats |
/stats endpoint |
The First Real Scan
I ran the first auto-scan on a test banking app login screen. Five interactive elements. Only two had labels.
Result: D — 40% accessible
Recommendation: "Urgent. Most elements are invisible to screen readers. Immediate fixes required."
That's the entire point. A real banking app with that score would be unusable by blind customers.
What Broke
The deploy failed multiple times. First, Render couldn't find the port. Then it couldn't find models.py. Then the build cache held onto old code. Each error taught me something about how Render handles deployments. I fixed the start command to use $PORT, created the missing files, cleared the build cache, and redeployed.
Three hours of debugging. Ten minutes of actual feature work. That's real engineering.
What Works Now
-
/scan— Auto-scan from Android UI tree XML -
/stats— Aggregate statistics from Supabase -
/audits/recent— Recent audit history - Supabase persistence — Every audit saved
- Full pipeline — Request → Parse → Score → Save → Respond
What's Next (Day 3)
- Build a public dashboard showing all audited apps and scores
- Connect real app scanning to my Phone Agent's UI tree output
- Start scanning Nigerian banking apps for real
The Repo
👉 github.com/Dexter2344/accessbuild-api
Day 2 is done. The API has a memory now.
— Dexter
Top comments (2)
The jump from pasted elements to scanning a real Android UI tree is the important product step here. A D score is actually useful feedback because it exposes gaps the manual path can hide. The next thing I would measure is whether rescans stay stable when the screen changes slightly, since accessibility tools live or die on predictable findings.
Great point about rescans staying stable. That's actually the next thing I'm building.
Right now, the API scores whatever UI tree it receives. But you're right if the same screen produces different results on consecutive scans, the tool loses credibility. Accessibility tools need predictable findings.
My plan for Day 3 is to add a "scan stability" check: scan the same screen 3 times and compare results. If the scores differ, flag it. That way, the tool tells you when its own findings are unreliable, not just when the app is inaccessible.
Appreciate the feedback this is exactly the kind of thing that separates a prototype from a real tool.