Question pages

When to use

Read this before laying out any form with more than three questions in it.

"One question per page" is the pattern popularised by GOV.UK and adopted by the NHS service manual, and it is a genuinely good default: each screen has one thing to understand, one thing to get wrong, one error to recover from, and one heading that says what is being asked. On a phone it removes almost all of the layout problem.

It is a default, not a law, and health products contain several situations where it is the wrong answer. This page is about telling those apart.

Use one question per page when:

• The question is hard, sensitive, or unfamiliar.
• Getting it wrong has a consequence: a dose, a date, a unit.
• The answer changes what is asked next.
• The reader is doing this once, or rarely.

Use a grouped page when:

• The fields are genuinely one thing to a reader who is not you: a systolic and a diastolic reading, a height in feet and inches, a start date and an end date. Splitting these makes the form longer and harder, because the reader now has to hold half an answer across a page transition.
• The reader is copying from a physical source such as a meter, a label or a printed result, and moving between fields is faster than moving between pages.
• The reader is doing this every day and knows every field by heart. See Daily logging.

When not to use

• The instrument fixes the layout. A validated questionnaire's item order and presentation may be part of what makes its scoring meaningful. Do not re-paginate it for aesthetics; treat it as fixed and design around it.
• You are asking for one specific well-known field. The answer for a date of birth or a name is already worked out in Ask users for…; go straight there.
• The reader is reviewing, not answering. A summary of everything they entered is a review screen and should show everything at once, with edit links.
• You want the wiring. Multi-step form state, resumability and routing are Handbook → Forms.

How it works

flowchart TD
A["A set of questions"] --> B{"Would a reader call these one thing?"}
B -->|"yes"| C["Group them on one page under one heading"]
B -->|"no"| D{"Does the answer change what comes next?"}
D -->|"yes"| E["One per page, so branching is invisible"]
D -->|"no"| F{"Is it sensitive, unfamiliar or high-consequence?"}
F -->|"yes"| G["One per page"]
F -->|"no"| H{"Is the reader doing this daily?"}
H -->|"yes"| I["Group, and optimise for speed"]
H -->|"no"| G

Whichever you choose, these hold:

• The question is the page heading. It is not "Personal details" with a label underneath. The <h1> is the question. This is what makes one-per-page work for screen readers, and it is the part most often dropped when teams copy the pattern visually.
• A grouped page has a group heading and a fieldset. "Blood pressure" as a legend with two labelled controls inside it. Two loose inputs with a caption above them is the same thing rendered wrongly.
• Progress is stated, not implied. "Step 3 of 6" in text. A bar alone tells a reader nothing about how much is left and is unavailable to anyone who cannot see it.
• Back always works and never destroys. Browser back, the platform gesture and an in-page back control all return to the previous question with its answer intact.
• Never mix branching with grouping. A grouped page whose fields appear and disappear as the reader answers is the hardest possible form to use with assistive technology. If it branches, split it.

The cost of one-question-per-page

Be honest about it rather than pretending it is free:

• More navigations, which means more state to persist and more places to lose it.
• A reader cannot see the whole shape of what is being asked, which matters when they are deciding whether to start at all.
• Copying from a physical document becomes slower, not faster.
• On a wide screen it can look absurd. A single field sits in the middle of 1400 pixels. Handle that with layout, not by regrouping; see Responsive modes.

Content

Accessibility

• One <h1> per page and it is the question. Focus moves to it on navigation, so the first thing announced is what is being asked.
• Grouped fields use fieldset and legend. The legend is announced with each control's label, which is exactly the context a grouped page needs and the reason a styled <div> is not a substitute.
• Progress is real text in the document, associated with the step, not an aria-label on a decorative bar.
• Answers survive back-navigation, as required by WCAG 2.2 SC 3.3.7 (Redundant Entry). A wizard that clears on back is the most common failure of this pattern.
• No auto-advance. Moving to the next question when a field looks complete removes the reader's ability to check their answer and is disorienting with a screen reader. This includes segmented code inputs.
• The submit control's label names the outcome: "Save reading", not "Continue", where continuing is what actually stores something.

Research

Updates to this page

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