Ask users for height and weight

When to use

Ask for height and weight when a named calculation or a named piece of guidance depends on them, such as a dose, a body-surface-area calculation, an eligibility threshold, a chart the reader has asked to see.

Two things make this field harder than it looks. First, the units are compound and regionally split: a British reader is likely to think in feet and inches and in stones and pounds, an American reader in feet and inches and pounds, and much of the rest of the world in centimetres and kilograms. Handling only one of these is a correctness failure, not a localisation nicety.

Second, this question is difficult for some readers. Weight is the field most likely to be abandoned, most likely to be answered inaccurately, and most likely to cause distress to someone with a history of disordered eating. That is a design constraint, not a footnote.

When not to use

• You want it for a chart the reader did not ask for. A weight trend on a home screen is a decision, and for some readers it is the wrong one. Make it something the reader opts into and can turn off without losing the data.
• You need a category, not a number. If a dose band or an eligibility check needs "over or under X", ask that.
• Height for an adult, more than once. Adult height does not change meaningfully. Ask once, store it, allow editing, and never re-ask.
• You want display rules. Rounding and precision for the stored value are Numbers, units and precision; the unit systems themselves are Unit systems.

How it works

flowchart TD
A["We need height or weight"] --> B{"Adult height, already known?"}
B -->|"yes"| C["Do not ask again; show it with an edit control"]
B -->|"no"| D["Ask, with the reader's unit system defaulted and switchable"]
D --> E{"Compound unit?"}
E -->|"feet and inches, stones and pounds"| F["Separate fields under one legend"]
E -->|"cm or kg"| G["Single field, unit shown beside it"]
F --> H{"Physically possible?"}
G --> H
H -->|"no"| I["Reject, naming the accepted range"]
H -->|"yes"| J["Accept; store canonically, display in the reader's unit"]
J --> K{"Are we deriving BMI?"}
K -->|"yes"| L["Show its limits with it, or do not show it"]
K -->|"no"| M["Done"]

• Both unit systems, always, with the switch adjacent to the field. Not buried in settings. A reader who has to leave the form to change units will guess instead.
• Compound entry is separate fields under one legend, such as "Height: Feet, Inches". Never use one field expecting 5'11". See Units and numeric entry.
• Switching units converts what was entered, visibly. 12 st becomes 76.2 kg, not 12 kg.
• Bounds are physical, not typical. Human height and weight span a much wider range than a designer's intuition; rejecting a genuine value is worse than accepting an implausible one, which can be confirmed rather than blocked.
• Never require a weight to proceed unless a calculation genuinely cannot run without it, and if it cannot, say which calculation.
• Do not congratulate, compare or editorialise. No "great progress", no target lines the reader did not set, no comparison to a population average. See Daily logging.

About BMI

If you derive BMI, three rules apply, and they are the reason this section exists:

1. Never show a BMI category as a clinical status. "Obese" as a red pill is the status axis being used to deliver a judgement about a person, which is exactly what The two colour axes prohibits.
2. Show the limits alongside the number. BMI is a population-level screening measure derived from height and weight alone. It does not distinguish muscle from fat, and its standard cut-offs are not equally applicable across all populations. A number presented without that context will be read as a verdict.
3. Let the reader turn it off. A reader who does not want to see it should not have to see it to use the rest of the product.

If your product cannot follow all three, do not derive BMI.

Content

Accessibility

• No autofill token exists for height or weight. autocomplete="off"; prefill from the reader's own previous entry instead. See Autocomplete and input types.
• type="text" with inputmode="decimal", never type="number" with a spinner. The scroll wheel silently altering a weight is a real failure.
• Compound fields are a fieldset with a legend, so each part is announced as "Height, feet".
• Units are spelled out in the accessible name: "Weight in kilograms".
• A unit switch announces the converted value as a polite status message (WCAG 2.2 SC 4.1.3).
• Errors name the bound: "Enter a weight between 20 and 400 kg" (WCAG 2.2 SC 3.3.3).
• Do not re-ask height. WCAG 2.2 SC 3.3.7, and it is also simply rude.

Research

Updates to this page

Last read through against the system on 2026-09-20. Due for review every 6 months; expiry is reported by pnpm run check:freshness.