Rethinking MyTwin for blind and visually impaired people: what our first accessibility work taught us

Vision impairment is common: according to the World Health Organization, at least 2.2 billion people live with a near or distance vision impairment. Many still read a screen, with glasses or larger text. Others, blind or with very low vision, use a screen reader, which reads the interface aloud, one element at a time.

For them, most of the web still falls short. In February 2026, WebAIM’s automated scan of the home pages of one million websites found failures of the Web Content Accessibility Guidelines on 95.9% of them, and automated tools only catch part of the problems. A health app is no place for that gap: results, appointments and treatments are exactly what a person should be able to reach on their own.

The classic approach is to annotate what already exists: give each button a name, each image a text alternative, each control a role the screen reader can announce. It is necessary, and it is where the work on MyTwin started.

It quickly showed its limits. Labels make each element readable; they don’t make the whole understandable. Added without rethinking the screen, they can even make things worse. The W3C’s guide to ARIA, the attributes that describe an interface to assistive technologies, opens on the principle that “no ARIA is better than bad ARIA”. In WebAIM’s scan, home pages using ARIA had more detected errors on average than those without it, 59.1 against 42.

Real accessibility asks for a design effort, and for code structured to carry it: the order in which elements come, how they are grouped, what is announced and when, how many steps a screen asks for.

The deepest difference is in how a screen is read. A sighted user takes it in at a glance, skips what doesn’t interest them and goes straight to what they came for. A screen reader user moves through it one element at a time, heading, button, text, menu, until they have the whole picture and can decide where to go.

That is why structure matters so much. In WebAIM’s latest survey of screen reader users, 71.6% find their way on a long page through its headings: headings are how they skim. An interface that only makes sense visually, with meaning carried by position, colour or density, leaves them to read everything.

Most interfaces designed for sighted people don’t survive that reading. Fixing them sends you back to the primitives of product design: what is this screen for, what comes first, what can wait. The questions are simple. Answering them honestly is the real work of accessibility.

Even a well-structured app keeps part of the gap: a screen reader user still has to go through a screen to know what is on it. Hence the direction we want to explore next, an app you can drive entirely by voice. Instead of walking through the interface, you would ask for what you need, “show me my last blood test”, and the app would take you there.

The idea is to decouple accessibility from the interface: alongside screens that can be read, a way to reach what you need without going through them. It doesn’t replace the work on structure, which screen reader users still need. And today it is only an idea: none of it is built yet.

This first work is preliminary. The next steps will be taken on MyTwin Lab, as challenges open to the community: continuing the work on the app, and exploring voice control. Each of them will be told here.

They will need people who don’t often work on the same project: designers, developers, and above all people who use a screen reader every day, whose experience no checklist replaces.