Accessibility is often bolted on at the end of a build, discovered in a pre-launch audit, and fixed under time pressure. For a patient portal that is the wrong order entirely: the people most likely to depend on assistive technology are often the people who most need to reach their health information. We built this one the other way round — accessibility first, everything else in service of it.
Design to the standard from the first wireframe
We treated WCAG 2.2 AA as a design input, not a test at the end. Heading structure, landmark regions, colour contrast and focus order were decided while the interface was still a wireframe, so the accessible version was the design — not a parallel one to reconcile later. Every interactive component was built to be fully keyboard-operable, with a visible focus state and an accessible name, and validated with a screen reader as part of the same task that created it.
Make the essential flows calm and fast
The core journeys — booking an appointment, reading a result, sending a secure message — were rebuilt to load and respond instantly and to give specific, plain-language feedback when something went wrong. Sensitive, regulated steps kept every safeguard they needed; the friction that wasn’t doing a job came out. The portal ended up faster and clearer for all patients, which is the usual dividend of building accessibly: it is simply better design.
The figures here are illustrative of what this kind of accessibility-first web application work delivers; this is a representative, industry-level example and the client is not named. What carries across is the principle: design to the standard from the start, test with real assistive technology, and never treat any patient as an edge case.
If you’re building a product that has to be accessible — legally, or because your users depend on it — that’s the work our web development and design teams do together. Start a conversation.