Standards and devices

• No target under 24 × 24 px: 24 × 24 px at the very least. People tap the wrong thing, or need several tries. (WCAG 2.2: 2.5.8 Target Size (Minimum))
• Touch controls at 48 px: 48 × 48 px on touch. Controls that are fine with a mouse become a struggle with a thumb, above all on the move. (From Android (48 dp), Apple (44 pt) and WCAG 2.5.5 (44 px, AAA))
• 44 × 44 px is the strict accessibility level: 44 × 44 px. People with tremors or limited dexterity cannot hit smaller controls reliably. (WCAG 2.2: 2.5.5 Target Size (Enhanced))
• Size by pointer, not by width: @media (any-pointer: coarse). Small controls on touchscreen laptops and big tablets, because the width looked like a desktop. (MDN: pointer)
• Mouse controls can be smaller, not tiny: 44 px default, 28 px for dense tools, never under 24 px. Dense toolbars that a mouse can manage but nobody else can. (Apple Human Interface Guidelines: Accessibility)
• Space between neighbouring targets: 8 px (house rule, from about 2 mm). Tapping “Delete” while aiming for “Save”. (Touch Targets on Touchscreens (Aurora Harley, NN/g))
• A pixel is not a size on a finger: At least 1 × 1 cm on the device. A size that looks fine on the design monitor is too small in the hand. (Touch Targets on Touchscreens (Aurora Harley, NN/g))
• Field text at 16 px or more: font-size: 1rem (16 px) or larger. iPhone Safari zooms the whole page in when you tap a field with smaller text, and leaves it zoomed, so the layout seems to break. (16px or Larger Text Prevents iOS Form Zoom (Chris Coyier, CSS-Tricks))
• Field height matches the buttons: 48 px on touch, 44 px otherwise (house rule, from the target rules). Fields you keep missing, and a row of controls that doesn’t line up. (From the target size rules above)
• A visible label above every field. Halfway through a form you no longer know what a field was asking. (GOV.UK Design System: Text input)
• Labels tied to their field. A screen reader announces only “edit text”, and tapping the label doesn’t focus the field. (WCAG 2.2: 3.3.2 Labels or Instructions, 4.1.2 Name, Role, Value)
• The visible words are in the name. Saying “click Send” in voice control does nothing, because the code calls the button “Submit form”. (WCAG 2.2: 2.5.3 Label in Name)
• Say what a field is for: autocomplete="email" and so on. People type out their address on a phone keyboard while the browser already knows it. (WCAG 2.2: 1.3.5 Identify Input Purpose)
• Bring up the right keyboard: type and inputmode per field. Looking for the @ sign, or switching keyboards for every digit of a postcode. (GOV.UK Design System: Text input)
• No autocorrect on names and codes: spellcheck="false" autocapitalize="none" autocorrect="off". The phone “corrects” your surname or street, and nobody notices until the parcel goes astray. (GOV.UK Design System: Text input)
• Neighbours line up: Bottom-aligned rows, one height, one left edge. A button half a line above its field, a header that starts 16 px left of the page, a button as wide as the screen. (From the field height rule above; the rest is this atlas’s own judgement)
• Field width shows the answer’s length: Postcode 10 characters when alone in a column. A full-width postcode field looks as if it wants more; a cut-off number is simply wrong. (GOV.UK Design System: Text input)
• Never block pasting. Password managers fail, and people retype long numbers by hand and get them wrong. (GOV.UK Design System: Text input)
• Errors say what to do. A red edge with no explanation, or a form that empties itself. (WCAG 2.2: 3.3.1 Error Identification, 3.3.3 Error Suggestion, 4.1.3 Status Messages)
• Don’t ask twice. Typing the same address again at the next step of a checkout. (WCAG 2.2: 3.3.7 Redundant Entry)
• No surprises on focus or input. On a keyboard you try the second option, and the page has already gone. (WCAG 2.2: 3.2.1 On Focus, 3.2.2 On Input)
• Everything works by keyboard. A “button” made of a `<div>` that a keyboard can’t reach. (WCAG 2.2: 2.1.1 Keyboard, 2.4.3 Focus Order)
• You can see where the focus is: 2 px outline or thicker, 3:1 contrast. Tabbing through a page, with no idea where you are. (WCAG 2.2: 2.4.7 Focus Visible, 2.4.13 Focus Appearance)
• Sticky bars don’t hide the focus: scroll-padding-top/bottom = sticky height. Tabbing “disappears” underneath the sticky bar. (WCAG 2.2: 2.4.11 Focus Not Obscured)
• Nothing needs hovering: @media (hover: hover). A menu that only opens on hover never opens on a phone; on touch, a hover colour stays on after the tap. (WCAG 2.2: 1.4.13 Content on Hover or Focus)
• One finger, no dragging needed. A slider that works only by dragging; a carousel that nobody with a switch or a shaky hand can use. (WCAG 2.2: 2.5.1 Pointer Gestures, 2.5.2 Pointer Cancellation, 2.5.7 Dragging Movements)
• Enough contrast: Text 4.5:1, large text 3:1, controls 3:1. Unreadable in sunlight; low contrast is the most common failure on the web. (WCAG 2.2: 1.4.3 Contrast, 1.4.11 Non-text Contrast)
• Body text about 16 px on phones: 16 px or more. Pinching and panning to read each line. (Apple Human Interface Guidelines: Accessibility)
• Never turn off zoom: width=device-width, initial-scale=1. People with poor sight are stuck with the size you chose. (WCAG 2.2: 1.4.4 Resize Text)
• No sideways scrolling at 320 px: 320 px. Reading each line by scrolling sideways, on a phone or when zoomed in. (WCAG 2.2: 1.4.10 Reflow)
• Survive changed text spacing: 1.5 / 2 / 0.12 / 0.16. With a reading stylesheet on, text overflows its button or gets cut off. (WCAG 2.2: 1.4.12 Text Spacing)
• Both orientations work. Someone with a phone mounted on a wheelchair can’t turn it, and can’t use the page. (WCAG 2.2: 1.3.4 Orientation)
• No 100vh on phones: 100svh or 100dvh. The button at the bottom of a full-screen hero is hidden under the address bar; on scrolling, the page jumps. (The large, small, and dynamic viewport units (web.dev))
• Keep clear of notches and home bars: padding-bottom: calc(1em + env(safe-area-inset-bottom)). A sticky buy button underneath the phone’s home bar; swiping up leaves the browser instead of buying. (MDN: env())
• Moving content can be stopped: Pause control if it moves over 5 s. A slide changes while you are reading it; a person with attention difficulties can’t read at all. (WCAG 2.2: 2.2.2 Pause, Stop, Hide)
• Respect “reduce motion”: @media (prefers-reduced-motion: reduce). Motion can make people dizzy or nauseous. (WCAG 2.2: 2.3.3 Animation from Interactions)
• Don’t design to a thumb map. Key actions squeezed along the edges because a chart said so. (How Do Users Really Hold Mobile Devices? (Steven Hoober, UXmatters), with his 2017 comment)