case study: a bilingual, accessible self-management guide for heart and brain health
brainhearthealth.ca is a self-management guide for people living with heart disease, built for bruyère health and the canadian centre for aging and brain health innovation. six sections — nutrition, exercise, mental well-being, social support, daily wellness — with separate paths for patients and for caregivers, a services directory, and a full french mirror.
the quotes below are from the client's own google review.
the actual problem was translation, twice
the brief involved two different kinds of translation and only one of them was linguistic.
the first was clinical to plain language. the underlying material is evidence-based research written for people who read research. the audience is a patient managing a heart condition, or the family member helping them. those are not the same reader, and text that is accurate but unreadable fails at the only thing it exists to do.
the second was english to french at full parity. not a partial translation, not a summary page, not a language switcher that dumps you back on the homepage. a mirrored site where a francophone user gets the same guide, the same depth, the same navigation.
"they went above and beyond to build a website that better serves our target audience and is more accessible."
the audience decides the design
the readers are largely older, often reading on a phone, sometimes managing a condition that affects concentration. that is not an edge case to accommodate at the end — it is the primary user, and it settles most of the design decisions up front:
- type sized to be read without zooming, and line lengths short enough to track without losing your place.
- contrast that holds on a phone at low brightness, outdoors, on an older screen.
- structure that is real structure. a long guide is only navigable if its headings are genuine headings in the right order. a screen reader user moves by heading; a sighted reader skims by the same outline. get it right and both are served.
- it survives being enlarged. a layout that breaks at 200% zoom excludes a large group who never identify as disabled — they just find your site hard and leave.
- mobile-first, not mobile-also. the desktop layout was the derivative, not the original.
in ontario the aoda makes much of this a legal requirement for many organisations. it is worth doing regardless.
six sections, two audiences, two languages
the content architecture is where a project like this quietly succeeds or fails. six guide sections × patient and caregiver paths × two languages is a lot of surface, and it has to stay in sync as the research team revises.
we built it on payload cms so the team can edit content directly, with the french structure mirroring the english rather than living as a separate hand-maintained site. a guide that drifts out of parity within a year is worse than one that was never bilingual, because now one audience is quietly reading stale clinical guidance.
working with a research team
research teams review carefully and in detail, and they should — this is content people will act on with their health. what worked:
"they were easy to communicate with and extremely responsive to feedback throughout the project."
practically: short review cycles rather than one large reveal at the end, and changes made while the context was still fresh on both sides. clinical content cannot be built in isolation and unveiled.
if you are building something similar
- who is your hardest reader? design for them and the comfortable reader is served automatically. the reverse is never true.
- does it survive a screen reader and 200% zoom? test in week one. retrofitting accessibility costs several times what building with it does.
- who owns the plain-language pass? it is a distinct skill from both clinical writing and web design, and it is nobody's job unless it is assigned.
- if you are bilingual, is parity structural or manual? manual parity decays. build it so the two cannot drift.
- does aoda apply to you? for many ontario organisations it does, and the standard is more specific than most people assume.
we build these. if you have a resource that needs to reach people currently struggling to use it, that is the work we like most.