In form design, why is a single-column layout the usual default, and when may two fields share one row?

## What the pattern says A **single-column form** stacks every field vertically: one label, one input, then the next, down the page. It is the default layout in most form guidance that design systems publish, and it is a **convention with reasons**, not a rule any standard mandates — WCAG says nothing about how many columns a form may have. The reasons are what an interviewer wants to hear, because they also tell you when the default may be broken. ## Why one column is the default - **One path.** In a single column there is exactly one next field. In a grid of fields, a user can read across the row or down the column, and people do each — so the field off their chosen path is the one that gets skipped. - **Visual order and navigation order agree.** Keyboard users, switch users and screen-reader users move through fields in sequence. When that sequence matches what a sighted user sees, nobody is surprised. Two columns make it easy for the two orders to drift apart. WCAG 2.2 success criterion **1.3.2 Meaningful Sequence** (Level A) asks that, when the order of content affects its meaning, a correct reading sequence can be programmatically determined; a single column makes that trivially true. - **Zoom and narrow screens.** A single column already is the narrow layout. A multi-column form must collapse at some width, and every collapse is another state to design and test — on a phone, under heavy zoom, in split-screen on a tablet. - **Scanning labels.** With labels above inputs in one column, the eye travels straight down one line of labels. Side-by-side fields break that line. - **Visible progress.** Movement down one column shows at a glance what is done and what is left. ## When two fields may share a row The honest exception is a pair of **short fields that users think of as one answer**. They go on one row as a unit, under a shared group label when they need one, and they stack again when space runs out. | Pair | Share a row? | Why | |---|---|---| | Card expiry month and year | Yes | One date, two small inputs, entered together | | Postcode and city, in address formats that print them on one line | Often | Read as one line of an address | | Given name and family name | Sometimes | One answer in many locales; a single name field avoids forcing a split that some names do not have | | Email and phone | No | Two separate questions; the second is easy to miss | | Party size and special requests | No | Different kinds of answer and very different lengths | The test to state: **if a user could reasonably answer one field and forget the other, they belong on separate rows.** ## Grouping and order do the real work A long form is made readable by grouping, not by columns: 1. Split the fields into groups that match how people think about the task — guest details, booking details, preferences. 2. Give each group a short visible heading, and expose the group to assistive technology as a labelled group so its heading is announced with the fields. 3. Use more space between groups than between fields inside a group, so proximity shows the structure before anyone reads a heading. 4. Order groups, and fields inside them, the way users hold the information: what they know first comes first. The column order of a database table is irrelevant to the person filling the form. 5. Put rarely used optional fields late in their group, or behind a disclosure, rather than interleaving them with essential ones. ## The wide-tablet trap A restaurant point-of-sale app runs on a landscape tablet, and the screen is wide. The temptation is to fill it: a new-reservation form laid out as three columns so nothing scrolls. In a busy service a host reads down the first column, taps save, and never sees the phone field sitting in column two — the reservation is stored with no way to reach the guest. A single column held to a comfortable width, with the floor plan or a live summary of the booking in the space beside it, keeps one unambiguous path and still earns the screen's width. The same form on a phone-sized handheld then needs no second layout. ## How a design system writes it down A form-pattern page usually states: - **Default:** one column of fields, labels above inputs, with a maximum form width so inputs do not stretch across the screen. - **Allowed exception:** short related fields that form one answer may share a row and restack when narrow. - **Groups:** labelled groups, with larger spacing between groups than within them. - **Order:** the user's order, confirmed in usability testing rather than inferred from the data model. Native mobile form guidance follows the same shape — stacked rows grouped into titled sections — so the rule reads the same on every platform the system ships to, and product teams can apply it without asking the system team case by case.