Designing a screen for low vision and tremor

Why platform minimums are the wrong starting point

Apple asks for 44pt touch targets and Android for 48dp. Those numbers describe the smallest thing a typical adult can reliably hit. They were never meant as a target for a screen whose whole job is to be usable by somebody with a tremor, in poor light, without their glasses, possibly in a hurry.

Designing to a minimum also means designing to the best case. The person using this screen at four in the afternoon in good light is not the person using it at two in the morning, and it is the second one the sizes have to work for.

Touch targets

132pt — a primary button on the screen used to ask for something.

88pt — the hard floor on that screen. Nothing goes below it, whatever the layout is doing.

56pt — controls on the screen used by somebody triaging a queue, which is a different job with different constraints.

8pt — the minimum gap between two adjacent targets.

132pt is roughly three times the platform minimum, and the size is doing two separate jobs. It is large enough to hit with an unsteady hand, and large enough to find without hunting — which for somebody with low vision is often the harder of the two.

The separation matters more than people expect. A tremor turns a tap into a short drag, and two large buttons flush against each other are more dangerous than two small ones with a gap: the target is easy to hit, so the neighbour is easy to hit by accident. Grow the gap before you grow the button.

Type

38pt / 44pt — the label on a primary button.

44pt / 52pt — the line that says what just happened.

20pt / 28pt — body text.

15pt / 22pt — the smallest size that exists anywhere.

Body text at 20pt is where a lot of design systems put a heading. That is the point: there is no small print, because small print is where the important thing always ends up and it is unreadable to the person who most needs it.

Having no size below 15pt is itself the constraint. If the smallest step in the scale is still readable, nobody can accidentally make something unreadable — you cannot reach for a size that does not exist. That is worth more than any individual number here, and it costs nothing but the discipline of not adding one.

The status line is the largest text on the screen at 44pt, which surprises people. It is deliberate: the moment after pressing is the moment of maximum uncertainty, and the answer to “did that work?” should be readable from across the room.

Contrast

7:1 — a label against its button fill.

4.5:1 — body text, and any icon that carries meaning.

3:1 — outlines and the focus ring.

7:1 is WCAG’s AAA level, applied to the thing somebody has to read before acting. Buttons are solid blocks of colour rather than tinted cards for this reason — a tint that looks tasteful in a design tool is often the difference between a legible label and a guess.

One rule is worth stealing outright: we never claim the large-text exemption. WCAG lets text above a certain size pass at 3:1 instead of 4.5:1, on the reasoning that big text is easier to read. Our text is big because the reader has trouble reading, so the exemption assumes away exactly the person it is being claimed for. It is not used anywhere, and a script fails the build if it creeps in.

Never let colour carry the meaning by itself

Every state is a word, an icon and a colour together — never a colour alone, and never an icon alone. A green dot means nothing to somebody who cannot distinguish it from the amber one, and icons are far more ambiguous than the person who chose them believes.

The cheap test: screenshot the screen, desaturate it, and see whether you can still tell what is going on. If you cannot, neither can a meaningful number of your users, and the fix is usually one word.

Nothing should move under a finger

Content that arrives late and pushes the layout down is a mild annoyance for most people and a genuine failure here: somebody who has begun a slow, deliberate reach at a button will land on whatever moved into its place.

Reserve the space before you have anything to put in it. We hold 300pt open on the main screen whether or not there is a message, precisely so that an arriving message never moves a button. It looks wasteful in a mockup and it is not.

For the same reason, nothing auto-scrolls, nothing auto-dismisses, and nothing reloads itself while somebody might be mid-reach.

Put the numbers somewhere a build can check them

The practical half of all this: none of it survives on good intentions. Ours live in one machine-readable file that both the app and this page read from, and a script checks every colour pair against the ratios above and fails the build on a violation.

That is why the numbers on this page are the real ones — they are read from that file at build time rather than typed here. A page describing your accessibility standards is exactly the kind of page that goes quietly out of date, and the only reliable fix is to make it impossible rather than to remember.

What this page will not tell you

We build software for sending a short message to somebody who agreed to receive it. That is the entire extent of what we know, and these pages stay inside it.

• Assessing anybody’s vision or motor control. These are design floors chosen to be safe for a wide range of people, not a substitute for finding out what one particular person can actually use.
• Screen reader and switch access design. Both matter enormously and neither is what this page is about.
• Cognitive accessibility as a field. Some of what follows helps, but we are describing what we built rather than summarising research we did not do.
• Whether a screen is the right answer at all. Sometimes a physical switch, a bell, or a person is better, and no amount of type scale changes that.