Pre-selected defaults: when the form has already answered for you

What it is

Every form field ships in some state. A checkbox is either checked or not; a radio group either has a selection or does not; a text input either holds a value or is empty. There is no neutral option, which is what makes the default a design decision rather than a technical detail. Whatever state you ship becomes the answer for everyone who does not intervene.

The manipulative version of this takes two shapes. The first is opt-out-by-default: a checkbox for marketing email, data sharing, an added warranty or a recurring subscription arrives already ticked, and declining requires the user to find it and untick it. The second is the pre-filled value: a text input contains something plausible that the user is expected to replace, and if they do not, the placeholder-ish content is submitted as if it were their answer.

The Prefilled Form, the game level this page accompanies, is built on the second shape and adds the twist that makes it work. The form opens with the name field containing “John Smith”, the email field containing “[email protected]”, and other fields similarly populated — all styled in the grey normally reserved for placeholder text. Every field is correctly labelled. Nothing is hidden. The form simply looks finished, because grey text in a box is a signal people have learned to read as “nothing here yet”. Submitting rejects the sample values, which is usually how players discover they were there at all.

That grey is the whole trick, and it is the inverse of the placeholder-as-label problem. There, real hint text is mistaken for content the user must clear; here, real content is mistaken for a hint that will clear itself. Both failures come from the same source: the visual language of a form field carries no reliable distinction between “this is your data” and “this is an example”.

Why it works on people

Defaults work because changing one costs something and accepting one costs nothing. Johnson and Goldstein made this concrete in Science in 2003, comparing organ-donation registration under opt-in and opt-out arrangements. Their argument is that every policy must have a no-action default, and that defaults impose physical, cognitive and emotional costs on anyone who wants to depart from them. Their evidence is that changing which state is the default changes the resulting rate of agreement substantially — not by persuading anybody, simply by relocating the effort.

A default also reads as advice. A form that arrives with an option selected is implicitly saying that this is the usual, expected or recommended answer. A user who is uncertain — and on an unfamiliar form most users are — has a reason beyond laziness to leave it alone.

Pre-filled text exploits a narrower mechanism: the convention that grey means inactive. Users scan a form for empty fields to fill, so a field that does not look empty is skipped by the scan entirely. This is the flip side of a documented usability problem with placeholders, which Nielsen Norman Group summarises as users mistaking placeholder text for prefilled data and skipping the field. Prefilled data styled as a placeholder inverts the mistake, and the interface gives no cue that would let the user distinguish the two cases.

For assistive technology the ambiguity is worse, because there is even less to go on. A screen reader announces an input’s value as the field’s content, so a pre-filled name field is announced as containing “John Smith” with nothing signalling that this is an example rather than a saved answer. A pre-ticked checkbox is announced as “checked”, which is identical to how a box the user ticked themselves is announced. The grey styling that is a weak cue for a sighted user is not exposed at all.

None of this makes defaults illegitimate. Defaults that save real effort — country pre-selected from locale, quantity of one, the shipping address you used last time — are among the most useful things a form can do. The distinction is who benefits when the user does nothing.

Where you meet it

• A newsletter or “partner offers” checkbox arriving ticked at the end of a checkout, below the fold and above the submit button.
• A subscription plan selector where the annual, higher-total option is pre-selected and presented as the recommendation, with the monthly option smaller and further down.
• Add-ons — insurance, priority handling, an extended warranty — pre-added to a cart so that the displayed total already includes them.
• A donation or tip step where a non-zero amount is preselected, so leaving it alone is a payment.
• Privacy settings that ship at their most permissive, described as “recommended”, with the restrictive options collapsed behind an “advanced” or “manage” link.
• A profile form pre-filled with values inferred rather than provided — a guessed country, a guessed job title — presented in the same styling as data the user actually entered.
• A free trial with automatic conversion to a paid plan pre-selected, where the no-action outcome is a charge.
• Cookie banners where non-essential categories arrive toggled on, which is the case European regulators have addressed most directly.

Designing around it

• Ship consent unchecked. Under the GDPR, Recital 32 states that “Silence, pre-ticked boxes or inactivity should not therefore constitute consent”, and in Case C-673/17 the Court of Justice of the European Union held in October 2019 that consent is not validly given where storage of or access to information on a user’s device is permitted by a pre-checked box the user must deselect. In markup terms: omit the checked attribute. Nothing else in the field needs to change.
• Never put example content in a value. If you want to show what an answer should look like, use the placeholder attribute so the browser clears it on input, or put the example in a hint element referenced by aria-describedby. A value is an answer; treat it as one.
• When you do pre-fill from real data, make it look like data and say where it came from. Render it in the same colour and weight as text the user typed, and put a short note next to the field — “from your last order, edit if it has changed” — connected with aria-describedby so it is announced with the field. The user should never have to guess whether a value is theirs.
• Choose defaults on behalf of the person filling the form, not the business collecting it. A useful rule of thumb: if the default were flipped and your conversion rate fell, you have learned that the default was doing the deciding. For anything with a cost, a commitment or a privacy consequence, the no-action outcome should be the smaller one.
• For genuine questions, ship radio groups with nothing selected, so that “I have not answered” is a distinguishable state from “I chose the first option”. Group them in a fieldset with a legend that carries the question, so a screen reader announces the question before the options rather than reading five bare labels.
• Solve typing effort with autofill rather than with pre-filled values. Add autocomplete tokens to every field that has one — name, given-name, family-name, email, tel, street-address, address-level2, postal-code, cc-name, cc-number — which is what WCAG 2.2 SC 1.3.5 Identify Input Purpose (Level AA) asks for. Autofill puts the user’s own data in the field on their action, which is the outcome pre-filling was pretending to offer.
• Add a review step before anything consequential. List the values as plain text rather than as inputs, show the total with every added item named and priced, and let each line link back to the field that produced it. A confirmation screen is where a default that slipped through gets caught.
• Instrument the defaults you ship. Log the proportion of submissions that leave each pre-set field unchanged. A field where ninety-something percent of submissions keep the default is not measuring a preference; it is measuring the default. Track it separately for people who did open the settings, because that gap is the honest estimate of what people would choose if asked.
• Test with a screen reader and with autofill both on and off. Tab through the form without looking at it and write down what you believe every field contains; then look. Anything you got wrong is a place where the visual and the programmatic states disagree.

Questions

Are pre-ticked checkboxes legal?

Not for consent under EU data protection law. GDPR Recital 32 states that silence, pre-ticked boxes or inactivity do not constitute consent, and the Court of Justice of the European Union confirmed in Case C-673/17 (Planet49, October 2019) that a pre-checked box the user must deselect is not valid consent for storing or accessing information on their device. Rules differ by jurisdiction and by what the box is for, so treat this as the standard to design to rather than a summary of every applicable law.

Why do pre-selected defaults change what people choose?

Because accepting a default costs nothing and changing one costs attention, effort and a decision. Johnson and Goldstein’s work on organ-donation defaults shows that switching which option is the no-action outcome moves agreement rates substantially without changing anything about the underlying choice. A default also reads as a recommendation, which gives an uncertain user a reason to leave it alone.

Is it always wrong to pre-fill a form field?

No. Pre-filling with the user’s own data — a saved address, a previous order, a country derived from their locale — removes real work and is one of the most valuable things a form can do. The line is drawn by two questions: is this value actually theirs, and does it look like a value rather than a hint? Style pre-filled data exactly like typed data, say where it came from, and never put example content into a field’s value.

What does a pre-filled field sound like to a screen reader user?

Like a filled-in field. Screen readers announce an input’s value as its content, so a field containing “[email protected]” is read as though the user had entered it, and a pre-ticked box is announced as “checked” exactly as a user-ticked one would be. The grey styling that gives a sighted user a weak hint is not exposed to assistive technology at all, which is why example content belongs in the placeholder attribute or a described-by hint rather than in the value.

Related patterns

• Cookie consent dark patterns: double negatives and asymmetric choice
• Hick’s law: the most misquoted number in interface design
• Password composition rules: why “one number, one symbol” backfires
• Placeholder text as a label: what breaks and what to do instead