TrueAccess
Whether you can actually get in
Venue accessibility in South Africa, assessed against the national standard by trained auditors — so that a disabled person can know before leaving home instead of phoning ahead.
- 115 commits
- 2025-10-16 → 2026-07-27
- TypeScript 46.2%
- private repository
Millions of disabled South Africans plan every outing around a single unknown: will I be able to get in, move around, and use the facilities? The available information is photographs and the phrase "wheelchair accessible", which one step, one narrow door or one missing toilet makes false.
The people who know are the people affected — but their knowledge lives in memory and group chats, unstructured and unsearchable. The build's bet is that this becomes useful the moment it is scored against something objective.
4 decisions
What the constraint forced.
Each of these is a choice with a reason attached. The reason is the part worth reading — a stack list tells you what was used, and nothing at all about the judgment that put it there.
- 01
Score against the published standard, not against opinion.
Every venue is assessed by a trained auditor against SANS 10400-S, the South African accessibility standard, and the compliance score is computed from that checklist. Ratings that are averages of impressions cannot be argued with or improved against. A score derived from a named standard tells a venue exactly which item to fix.
- 02
Disability profile data is never logged, never in a URL, never in an error.
The most sensitive field in the system is the one that makes the product work — what a given user needs. It is excluded from logs, from query strings and from error messages by policy, not by review. Under POPIA that is a legal position; independent of POPIA it is the difference between an app disabled people will use and one they will not.
- 03
Accessibility is the product, so the interface is held to the product's standard.
Every screen carries explicit accessibility labels and roles and holds a 4.5:1 contrast floor. This is stated in the journal as non-negotiable and it is the only honest position available: the users are disabled people, and an inaccessible app about accessibility is a contradiction that no feature can outrun.
- 04
Offline-first, data-light — because load shedding is real and mobile data is expensive.
Cached queries and offline map packs, lazy images, paginated lists, compressed uploads. The same pair of constraints that shapes VarsityOS shapes this: in this market, "assume connectivity" is not a simplification, it is a bug that only appears in the field.
The part that survives the build.
The sensitive field is usually the one the product is about.
Privacy engineering is easy when the sensitive data is incidental. It gets real when the sensitive data is the core index. The answer is not to avoid holding it — it is to decide, up front and in writing, which surfaces it may cross: never a log, never a URL, never an error string.
One codebase for iOS, Android and web is a decision about maintenance capacity.
With one engineer, three codebases is three times the surface for a fix to be applied twice and forgotten once. The universal router costs real flexibility at the edges and buys the only thing that matters at this size: every fix lands everywhere.
Built with
- Expo Router (iOS + Android + Web)
- TypeScript
- Supabase
- TanStack Query
- Mapbox (offline packs)
- PayFast
Measured
- commits
- 115
- last commit
- 2026-07-27
- journal sections
- 9
Written from TrueAccess build journal — dossier, 25 sections. The dossier is composed from the journal rather than quoted out of it — the raw sections stay behind the review gate described in docs/THE_FORGE.md §4, and every figure above is read from the GitHub API at build time.