Project Log #12: I Spent a Week Auditing Apps. The Results Changed This Project.

Day 12. I tested 15 popular Android apps for accessibility. What I found revealed who gets left behind.

I took a week off from coding.

Not because I was stuck. Not because I was tired. But because I needed to understand something that had been nagging at me since Day 10.

Why does my AI agent work flawlessly on WhatsApp but completely fail on my banking app?

The answer took a week of testing, documenting, and thinking. And what I found changed the direction of this entire project.

The Week-Long Audit

I tested 15 popular Android apps. For each one, I asked the same question: “Can my agent find and tap a core button using the UI tree?”

I spent hours opening apps, dumping UI hierarchies, parsing XML, and documenting every content description I could find. I wasn’t coding. I was investigating.

App UI Tree Labels Agent Can Automate? WhatsApp Excellent ✅ Fully Google Messages Excellent ✅ Fully Gmail Excellent ✅ Fully Google Maps Excellent ✅ Fully Spotify Good ✅ Mostly Slack Good ✅ Mostly Banking App A None ❌ Completely blind Banking App B None ❌ Completely blind Banking App C None ❌ Completely blind Local Food Delivery App Minimal ❌ Mostly blind Government Service App None ❌ Completely blind Telecom App Minimal ❌ Mostly blind

The pattern was impossible to ignore. Global apps had rich accessibility labels. Local apps had nothing.

What This Actually Means

Here’s the truth I wasn’t ready for.

Accessibility labels exist so that screen readers can tell blind and visually impaired users what’s on their screen. When a developer adds content-desc="Send message" to a button, they’re helping a blind person use WhatsApp.

WhatsApp invested in accessibility. Google invested in accessibility. Their apps are usable by millions of people with disabilities—and, accidentally, by my AI agent.

The local apps that skipped accessibility didn’t just lock out my agent. They locked out every blind and visually impaired person who needs to use that banking app, that government service, that telecom platform.

My AI agent is not the victim here. It’s a canary in a coal mine.

The Accessibility Divide

This divide follows a clear pattern. Global tech companies with large engineering teams and legal departments prioritise accessibility. They have dedicated accessibility engineers. They test with screen readers. They follow WCAG guidelines.

Local apps, often built by smaller teams with tighter budgets, deprioritise accessibility. It’s seen as a “nice to have” rather than a core requirement. The result is an entire class of applications that are unusable by people with disabilities—and by AI agents.

What I’m Doing About It

I’m adding an accessibility score to every app my agent supports. A simple A-F rating.

A — Fully automatable. Rich labels everywhere. (WhatsApp, Google apps)
B — Mostly automatable. Good labels with some gaps. (Spotify, Slack)
C — Partially automatable. Some labels, mostly generic.
D — Mostly blind. Few labels. Heavy reliance on OCR fallback.
F — Completely inaccessible. No labels. Unusable by both AI and screen readers.

This score isn’t just for my agent. It’s a public signal. If your app scores an F, you’re not just failing my project. You’re failing every visually impaired person who tries to use your service.

What’s Next (Day 13)

• Expand the audit to 30+ apps
• Publish the first version of the accessibility score list
• Start reaching out to local app developers about their accessibility gaps

The Repo

👉 github.com/Dexter2344/phone-agent

The audit results are being added to the README. The scoring system is documented.

This is Day 12. I spent a week not writing code. And it was the most productive week of this entire project.