From the research, farmers are interested in the results.
I spent about two days perfecting the health score animation. A smooth circular progress bar that fills with color, green for healthy, red for critical.
The Users I'm Actually Building For
Here's the uncomfortable truth about my target users:
This isn't edge-case accessibility. This IS the use case. A 55-year-old farmer with reading glasses she can't find, soil under her fingernails, standing in bright sunlight with one bar of signal, that's who needs this app most.
So I built the accessibility system around her, not around developers reviewing my code.
The Voice Button That Changed Everything
The single most impactful feature I built was embarrassingly simple: a button that reads the diagnosis/results aloud
I used the Web Speech API, which is built into every modern browser. The implementation took maybe an hour. But here's what I learned: the voice doesn't just help users who can't read. It helps everyone.
My mom tested it. She CAN read perfectly well. But she said hearing "Your tomato has early blight. This is a fungal disease. Severity is moderate" felt more trustworthy than reading the same words. Like getting advice from a person instead of a screen.
The voice script matters too. I don't just dump the JSON response into speech. I wrote it conversationally:
"Your tomato leaf has a health score of 45 out of 100. I detected Early Blight, which is a fungal disease. The severity is moderate. For treatment, you can use neem oil spray, mix two tablespoons with one liter of water, and spray every seven days."
Pauses between sections. Specific measurements. No jargon. The AI generates this because I asked it to in the prompt, "provide practical, actionable treatment steps that farmers can follow."
Font Scaling Without Breaking Everything
The accessibility settings panel lets users choose font sizes: Normal, Large, or Extra Large. Sounds trivial. The implementation taught me something about CSS architecture.
I changed the font size on the document root element. Every component using rem units automatically scales. No prop drilling. No context providers. One line of JavaScript, and the entire app responds.
The trick is building components with rem from day one. If you've hardcoded pixel values everywhere, retrofitting accessibility becomes a rewrite. I got lucky, Tailwind's default classes use rem, so most of my UI scaled correctly without changes.
The settings persist in localStorage. A farmer who needs large fonts shouldn't re-enable them every session. That would be the kind of "technically accessible" that's practically useless.
Touch Targets for Rough Hands
Apple says 44px minimum for touch targets. I went bigger.
Here's why: I watched my uncle try to use a banking app. His fingers are thick from decades of farm work. He kept hitting the wrong buttons. Not because he's clumsy, but because the app was designed by someone with smooth developer hands typing on a MacBook.
My button sizes:
- Standard buttons: 48px minimum height
- Primary actions (like "Analyze"): 56px minimum
- Bottom navigation: 64px minimum
The bottom navigation placement matters too. Thumbs naturally rest at the bottom of the phone. Putting the main navigation there means one-handed use actually works. Web convention says nav goes at the top. Mobile ergonomics says that's wrong.
Color That Works Without Reading
The health score uses a five-color severity system:
A user can glance at the color and know how worried to be. No reading required. The traffic light metaphor is universal, green means go, red means stop.
I chose these specific colors for three reasons:
Colorblind-safe progression: The luminance (brightness) decreases from green to red, so even without color perception, the severity reads correctly.
Sunlight visibility: High saturation colors remain distinguishable in bright outdoor light. Pastels wash out.
Cultural familiarity: Traffic lights exist everywhere. The metaphor translates.
Progressive Disclosure
A full diagnosis from Claude contains 25+ fields. Disease name, scientific name, confidence score, symptoms, causes, spread risk, urgency, treatments with ingredients and preparation steps, prevention tips, regional availability notes...
Showing all of that at once would overwhelm anyone, let alone someone who struggles with text-heavy interfaces.
The Settings That Actually Exist
I built an accessibility settings panel with five toggles:
- Font Size: Normal / Large / Extra Large
- High Contrast: On / Off
- Reduced Motion: On / Off
- Voice Mode: Off / On Request / Always On
- Simple Mode: On / Off
These settings persist in localStorage and apply instantly. The high contrast and reduced motion modes add CSS classes to the document root, the same pattern as font scaling.
"Simple Mode" hides secondary information and removes visual flourishes. For users who find options themselves overwhelming, fewer choices mean clearer choices.
What I Actually Built vs. the future
I call it the future since some of these features can still be added
What's working:
- Voice read-aloud for results (Web Speech API)
- Font size scaling (root-level CSS)
- Large touch targets (Tailwind minimums)
- Color-coded severity (5-level system)
- Progressive disclosure (collapsible sections)
- Settings persistence (localStorage)
- Bottom navigation (thumb-friendly placement)
What's partially done:
- High contrast mode (setting exists, CSS needs work)
- Reduced motion (setting exists, animations still run)
What's not built yet:
- Voice INPUT (speech-to-text for context entry)
- Multi-language support (Swahili, German, etc.)
- Offline mode for the actual analysis
Top comments (0)