The hardest person to design software for is not the power user. It is the person with the least practice — the one opening what is effectively their first app, on an older phone, over a patchy connection. Most software is built and tested by people fluent with software, so that person is the one who quietly disappears from the funnel. You rarely watch them leave; you just never see them arrive.

We ran straight into that constraint building Cidade na Colina — a free web app that puts Brazil’s evangelical churches on one map, so anyone can find a church nearby, see its service times, and add their own. The audience is the whole point: many are on older Android devices, treat WhatsApp as the internet, and may never have installed an app from a store. For them, accessibility stops being a checklist you run before launch and becomes the architecture you start from.

Accessibility is architecture, not a coat of paint

The industry usually treats accessibility as a late pass — bump the contrast, add alt text, run an audit, ship. That works when the product already assumes a confident user and you are widening the door a little. It fails when the least-comfortable user is the median user. Then the accessible path cannot be a side entrance; it has to be the main path, the one every feature is designed around.

If the accessible version is a separate, lesser path, you have built two products — and shipped the worse one to the people who needed the better one.

Remove the step that stops people: no login

The single most expensive screen in most products is the account. “Create an account, verify your email, set a password” is exactly where a first-time user puts the phone down. So there is no mandatory login anywhere: anyone can browse and find a church with no account, and anyone can add one with just the essentials. Curation moves to the back — submissions are reviewed and published within about 48 hours — instead of standing as a gate at the front. The friction that protects data quality should not be the friction a nervous first-time user hits first.

Meet people where they already are: WhatsApp-first

The primary action on every church is not a contact form or a generic “get in touch.” It is a WhatsApp button. For most of this audience, WhatsApp is where their entire digital life already happens; asking them to learn a new channel is asking them to leave. Designing to the tool people already trust beats teaching them a new one — every time you can manage it.

More than one way in: read it, hear it, say it

A form that only accepts precise typing excludes anyone who finds typing hard — which, for this audience, is a lot of people. So input is not one-dimensional. The registration flow accepts voice, so an answer can be spoken instead of typed. Any page can be read aloud with a one-tap “listen” button. Large text and a WCAG-AA high-contrast mode ship as first-class controls, remembered across visits — not toggles buried three menus deep for a minority.

  • Voice input on the registration form — speak the answer instead of typing it.
  • A “listen” button that reads the page aloud, for anyone who reads slowly or not at all.
  • Large text and a WCAG-AA high-contrast mode, remembered between visits.
  • One-tap presets for common service times, so a full schedule is a few taps, not a typing exercise.

Assume the connection will drop

On an older phone on mobile data, a multi-step form that loses everything on a refresh is a form that never gets finished. So the registration wizard autosaves to the device as you go: a dropped signal, an accidental back-swipe, or a phone call in the middle does not cost the work. Address entry has autocomplete with a postal-code (CEP) fallback for when autocomplete cannot place a spot. And the whole thing installs as a PWA — it behaves like an app without an app-store download, which for this audience is its own real barrier.

Accessible data is honest data

Accessibility is not only the interface — it is whether the information is true. An easy-to-reach answer that is wrong is worse than no answer, because it sends someone across town to a locked door. So the catalog is seeded from OpenStreetMap (open data, used under its ODbL license with attribution), and the service times people actually come for are filled in with AI grounded in web search — not guessed. Because AI can be confidently wrong, human curation still stands between a submission and the public map. Grounding and review are accessibility features; they just live in the data pipeline instead of the stylesheet.

Why this is engineering, not charity

None of this is softer than the optimization and AI work we do for clients. It is the same discipline pointed at a different constraint. “Works for everyone” is a system property: it lives in the auth model, in the form’s persistence, in the data pipeline, in how pages render and get read aloud — not in a class you add at the end. Bolt it on late and it stays shallow, and the people it was meant for slip through anyway.

The test is blunt. Hand the product to the person with the least practice and watch. If the main path is the accessible path, they finish — they find the church, they add their own, they move on. If accessibility was a coat of paint, they do not. And the cruelty of that failure is that you never see it in the analytics: the people you lost are exactly the ones who never made it far enough to be counted.