The cursor blinks on an empty button. It is not focused, not hovered, not pressed, and not disabled. It simply sits there, grey on grey, and the form will not submit. The user clicks once, twice, three times, then reloads the page. Nothing tells them why. This is what a UI looks like when layout, hierarchy, spacing, and component states were designed as separate checklists instead of one system. They are not four pillars; they are one behaviour under four names. Every one of them must survive contact with every interactive state.

What Layout Is For, and What Breaks It

Layout is the first thing a user sees and the first thing that collapses. A grid is not a constraint; it is a map of reading order. The CSS box model, content, padding, border, margin, is the unit of that map. Padding vs margin is not a stylistic choice. Padding is inside the border, margin is outside, and margin collapse will eat your vertical rhythm if you treat them as interchangeable. When a user tabs to a button and the focus ring clips against a neighbouring card because the margin was zeroed to save pixels, the layout has failed in its primary job: keeping interactive targets separable.

The failure mode is always the same. A viewport breakpoint set for a specific device width ages overnight; a breakpoint defined by content behaviour survives. On a 320-pixel screen, the layout stacks. On an error state, it must stack harder. Accessible layout demands that reflow happens at 200 percent zoom and at 400 percent zoom, with no horizontal scroll. WCAG 1.4.10 requires it. That is not a preference; it is a pass-fail test. Design the layout at three widths. Then test the error state at all three. Then test it with the browser zoom at 200 percent. Then test it with a screen reader that announces the focus order. If the focus order jumps because the grid rearranged but the DOM did not, the layout passes the visual test and fails the usability test.

Visual Hierarchy: The Order of Attention

Typographic Scale and Persistent States

Visual hierarchy is not about making things bigger. It is about making the next correct action the most likely place the eye lands, without a single word of instruction. Typographic hierarchy is the backbone: a type scale borrowed from Material Design 3 or Apple HIG layout guides gives you sizes that are mathematically related, not guessed. The headline at 32 pixels, the body at 16, the caption at 12. These are not arbitrary; they encode importance. But hierarchy must persist through states. When a button is loading, the spinner replaces the label, but the size must not shift, or the layout jumps and the user loses their place. When a field is invalid, the error message must sit in the same visual position as the successful state, or the user learns the wrong rule.

Contrast and Colour Independence

The contrast ratio is the metric that makes hierarchy honest. WCAG 2.2 sets 4.5:1 for normal text and 3:1 for large text; that is a floor, not a goal. A grey caption at 4.6:1 passes the checker but fails a user over 50 in sunlight. The checker sampled an antialiased pixel; the real text is dimmer. Run the formula (L1 + 0.05) / (L2 + 0.05) on the actual rendered colour, not the swatch, and verify at actual rendering size. Hierarchy that depends on colour alone, “the red text is the error”, fails the 1.4.1 use-of-colour criterion. The W3C notes that roughly 8 percent of men have a red-green deficiency. Add an icon. Add a border. Make the hierarchy legible without a single hue.

Spacing Systems and the Baseline Grid

Vertical Rhythm and the Spacing Scale

Spacing is the difference between a UI that feels cheap and one that feels engineered. It is the most commonly skipped principle because it is invisible when done right. A baseline grid is a vertical rhythm: all text aligns to a repeating interval, typically 4 or 8 pixels, so columns of adjacent text do not drift out of register. Leading at 120 to 145 percent of the type size keeps descenders from colliding. A body size of 16 pixels with 24 pixels of line-height is the default for a reason. The spacing system is not a set of arbitrary multiples; it is a scale of 4, 8, 16, 24, 32, 48, 64, where each step is a clear relationship to the next. Uniform rhythm is the clearest sign of a designed interface; its absence is the clearest sign of a rushed one.

State-Specific Spacing and Touch Targets

The state-specific rule is this: spacing must expand, not shrink, when a component changes state. A focused button with a visible focus indicator needs breathing room from the text next to it. Material Design 3 specifies 8 dp of tap target spacing as the minimum between targets, not around them. On a touch screen, the target size itself is the real constraint. WCAG 2.2 sets 24 by 24 CSS pixels as the minimum, but Apple HIG wants 44 by 44 points and Material wants 48 by 48 dp. Do not design for the 24-pixel minimum and call it accessible. Design for the platform requirement and treat the WCAG number as a legal floor. The difference between points and dp is not pedantry; they are different units on different devices, and mixing them produces a button that fails on one platform.

Interface Basics: The State Machine You Already Use

States Are the Spec

Interface basics usually stop at “make it pretty.” The craft is elsewhere: every component is a state machine, and the states are the spec. A button has at least five: default, hover, focus, active, and disabled. A text field has more: empty, filled, focused, invalid, error with message, disabled, read-only. Each state must be visually distinct, and the distinction must be more than a colour shift. Colour alone fails the 1.4.1 criterion. The disabled state is the one most often wrong. It is not a lighter grey with no explanation. It is a state that must be announced to a screen reader, with an ARIA landmark or a disabled attribute, or the user tabs into a thing they cannot use and does not know why.

Focus Order and the DOM

The focus order is the hidden layout. A user pressing Tab moves through the interface in the order the content appears in the DOM, not the order it appears visually. If the layout places the “Submit” button left of the “Cancel” button visually, but the DOM puts Cancel first, the keyboard user submits the form when they meant to cancel. This is not an edge case; it is the most common cause of accidental form submissions. The fix is not to reorder the visual layout to match the DOM. Reorder the DOM to match the reading order. That is the accessible layout principle most designers skip. Screen reader flow follows the same order. A user who navigates by headings should hear a logical structure: H1, then H2, then H3. Never a heading that jumps from H2 to H4 because the visual hierarchy was built with font-size overrides instead of real heading levels.

Component States: From Idle to Error

The State Contract

Component states in one paragraph: idle, hover, focus, active, disabled, loading, error, and success. Each state exists because the system must communicate what is happening, what will happen, and what has happened. An affordance is the property that makes a thing look like it can be clicked. A button with a border, a shadow, and a cursor pointer affords clicking. Remove the border and the shadow and it becomes a label that happens to be clickable. Progressive disclosure is the principle that hides advanced options until needed. It is a layout decision as much as a content decision, and it must not hide the error message that tells the user what they did wrong. Feedback state is the moment the system answers. A button that changes label from “Save” to “Saving…” to “Saved” is not decorative; it is a contract.

Loading, Error, and Success Without Layout Shift

The loading state is where hierarchy and spacing collide. A spinner that appears above the button pushes the button down, the form jumps, and the user’s eye loses the place. The fix is a fixed-height container that reserves space for the spinner, so the layout does not shift. The error state has the same problem. A message that appears below the field, pushing the submit button down, is a layout shift that fails WCAG 1.4.10 reflow and 2.2.2 pause-stop-hide if it is a carousel. Reserve the space. Use a fixed-height error container. The success state is no different. A green checkmark that appears and disappears without a pause fails the 2.2.1 timing adjustable criterion. Every state must be legible, must be announced, and must not move the thing the user is about to click.

Accessible Layout: The Minimum Is Not the Goal

Safe Areas and Keyboard Testing

Accessible layout principles are not a feature branch; they are the trunk. The safe area, the space inside the viewport where content is guaranteed visible, is the starting point, not an afterthought. On a phone with a notch, the safe area is defined by the platform. On a desktop browser, it is the viewport minus any fixed headers or footers. Content that scrolls under a sticky header fails the 2.4.10 focus not obscured criterion if the focused element is hidden. Test with a keyboard: tab through the page. If the focus ring disappears under the sticky nav, the layout has failed. The fix is a scroll-margin-top on the focused element, a CSS property that exists precisely for this failure mode.

Touch Target Size and Spacing

The touch target size is the other non-negotiable. WCAG 2.2 requires 24 by 24 CSS pixels minimum, but that number is a compromise for low-vision users on desktop; it is not a recommendation. Apple HIG recommends 44 by 44 points, Material Design recommends 48 by 48 dp. The two are not equivalent because points and dp are not the same unit. A target that passes at 24 pixels on a desktop monitor is nearly impossible to hit on a phone in one hand. Design for the larger target, then use the spacing system to keep targets separated by at least 8 dp so a mis-tap on one does not activate its neighbour. The failure case is a user with a motor impairment who taps “Delete” instead of “Archive” because both are 22 pixels and 4 pixels apart. That is not a design flaw; it is a lawsuit.

Typography: The Invisible Grid of Readability

Measure and Baseline Rhythm

Typography is layout at the character level, and it follows the same rules. Typographic measure, the number of characters per line, should sit between 45 and 75. Anything longer and the eye loses the next line; anything shorter and the text is choppy. The measure is controlled by the container width, not by font size alone. A 16-pixel font in a 900-pixel container gives a measure of roughly 56 characters, which is within range. The same font in a 1200-pixel container gives 75, which is at the edge. The baseline grid is the vertical counterpart: all text and all components align to a repeating interval, so the page has a rhythm. Leading at 120 to 145 percent of the type size is the range. Below 120 percent, descenders collide. Above 145 percent, the text looks like a ransom note. Kerning vs tracking is the distinction between the space between a specific pair, like “AV”, and the uniform space across a range of characters. Both adjust inter-character spacing; neither is a substitute for the other.

OpenType, Type Scales, and Legibility

OpenType is the format that makes typography possible across platforms, with support for ligatures, small caps, and old-style figures. A font without OpenType features is a set of pictures that happen to be letters. The type scale from Material Design 3 or Apple HIG is not a suggestion; it is a set of ratios tested for legibility. The body size is 16 pixels, the browser default, and it should not go below that for body text. A 12-pixel caption can pass the contrast ratio at 4.5:1 but fail the readability test because it is too small for extended reading. The x-height of a typeface, the height of lowercase letters relative to the cap height, determines whether a font is legible at small sizes. A font with a tall x-height will pass at 14 pixels where a low-x-height font fails at 16. Choose a font for its legibility at the sizes you actually use.

The Worked Example: A Form That Fails, Then Passes

Before: A Form That Breaks Every Rule

Here is the before-and-after that makes every principle concrete. The form has two fields, “Email” and “Password”, and a “Sign In” button. Before: the fields have no labels, only placeholder text that disappears on focus. The button is grey on white with no border. The focus state is a default dashed outline that is invisible on a light background. The touch target is 20 pixels tall. Error messages appear to the right of the field, pushing the button down and out of the viewport. The disabled state of the button is a lighter grey that a screen reader ignores. This form fails every single principle. It fails contrast on the placeholder text, which is 3.5:1 against white. It fails the focus indicator requirement because the dashed outline does not meet the 2:1 contrast ratio against the adjacent background. It fails the target size requirement at 20 pixels. It fails the error message requirement because the message is not programmatically associated with the field. It fails the disabled state requirement because the button is not announced as disabled.

After: A Form That Passes

After: the fields have persistent labels that stay above the input on focus, satisfying the label-and-instruction criterion. The button has a solid background, a visible border, and a focus ring that is 2:1 against the background, set with a not-allowed box-shadow. The target size is 44 pixels, meeting Apple HIG and exceeding WCAG 2.2’s 24-pixel minimum. The error message appears below the field in a fixed-height container, so the layout does not shift. It has an icon and a border, not just a red colour, and it is linked to the field with an aria-describedby attribute. The disabled state is announced by a screen reader as “dimmed, not clickable,” and the button does not receive focus when disabled. The loading state is a spinner in a reserved 44-pixel square, so nothing moves. The success state is a checkmark that stays visible for at least 2 seconds, satisfying the timing adjustable criterion. This is not a luxury version of the form; it is the minimum viable accessible form. The difference between the two is a list of failure modes you can name.

FAQ: Four Questions That Cover the Gaps

What is the single most common layout mistake?
Treating margin and padding as interchangeable. Margin is outside the border, padding is inside. Getting them mixed causes margin collapse that eats vertical rhythm, and a user cannot tell you why the spacing looks off. The fix is a token system: 4, 8, 16, 24, and never hard-coding a value.

Is the WCAG 2.2 target size of 24 pixels enough?
No. It is the legal minimum, and it fails usability for motor-impaired users. Apple HIG asks for 44 by 44 points, Material for 48 by 48 dp. Design for the platform recommendation, not the legal floor, and add 8 dp of spacing between targets to prevent mis-taps.

Why does my focus ring keep disappearing?
A fixed header or an overflow: hidden container is clipping it. The fix is scroll-margin-top on the focused element and a visible outline that has 2:1 contrast against the background. Test by tabbing through the page and watching the ring, not by looking at a static mock-up.

Can I skip the error state if the form is short?
No. A short form still fails if the error message is not associated with the field. A screen reader user must hear the field name, the error, and the fix in one announcement. Without an aria-describedby, the error is a guess, and the user abandons the form.

The Failure Case: When the Normal Route Is Closed

The normal route is the happy path: the user has a keyboard, a mouse, full vision, and no time pressure. The failure case is everything else. It is 1 a.m., the user is on a phone with a cracked screen, one hand, in a moving bus, and the form is too small to hit. It is a user with a motor tremor who cannot hold a 24-pixel button. It is a user with a screen reader who tabs into a disabled button that is not announced as disabled. They press Enter, nothing happens, and they do not know why. It is a user who zooms to 200 percent and the layout reflows into a single column, but the error message is now above the fold and they cannot see it. It is a user who fails the contrast checker at 4.5:1 because the checker sampled a pixel that had been blended with the background, and the real text is 3.8:1 and unreadable in sunlight.

When the normal route is closed, the design must have a plan. The plan is not a fallback page; it is the same layout with states that work. A focus indicator that is visible on a dark background and a light one. A touch target that is 44 pixels even if the design system says 32. An error message that does not rely on colour because the user is colour-blind. A loading state that does not move the button because the user is on a 3G connection and the spinner is more important than the label. These are not optional enhancements; they are the definition of accessible layout. If the design only works in a perfect environment, it does not work at all. The failure case is not a corner case; it is the average case, and it is the one that the WCAG 2.2 criteria were written to address.

How This Fits the Craft: The Worked Example Is Not a Template

This is a worked example, not a template. The mistake readers make is copying the example and assuming the job is done. The job is to take the principles, layout, hierarchy, spacing, states, and apply them to your own content, your own users, and your own failure modes. The example form has two fields; your form has ten. The example form has one error state; your form has a date picker with a range, a file upload, and a reCAPTCHA. The principles are the same, but the specifics are not. A date picker has its own state machine: an open calendar, a selected date, a date outside the range, a date in the past. A file upload has a drag-and-drop state, a hover state, a progress state, an error state for the wrong file type, and a success state with a thumbnail. Each state must be designed, tested, and documented. Each one is a place where the user can fail.

The documentation is where the craft lives. A design system is not a set of components; it is a set of states and the rules for moving between them. Material Design 3 and Apple HIG are the most complete public systems, but they are not the only ones. Any organisation with a product has its own system, and that system is only as good as its documentation of failure states. The designer who documents the disabled state for a button, the colour, the opacity, the screen reader announcement, has saved the developer a question and the user a moment of confusion. The designer who does not document it has created a gap that will be filled by a random guess. The craft is not in the making; it is in the naming of what can go wrong and the specification of how to handle it. That is what separates a UI that works from one that happens to be on screen.

Visual Hierarchy for the Adjacent Professional

What to Ask For

If you are a developer, a marketer, or a content writer who commissions or implements design, the specification language is the boundary you must not cross. You do not need to design; you need to know what to ask for. Ask for the type scale, and you will know whether the headline size was chosen by ratio or by guess. Ask for the spacing scale, and you will know whether the margins are part of a system or a series of hacks. Ask for the state list, and you will know whether the developer has been told what happens on hover, on focus, and on error. The ability to ask these questions is not a design skill; it is a diligence skill. It is the difference between approving a mock-up that looks good and shipping an interface that works. The mock-up is a single frame; the system is the whole film.

Using the Standard as Leverage

The in-house designer at a non-design organisation has a harder job: they are the only design-literate person in the room, and they need external authority to cite when advocating for process. WCAG 2.2 is that authority. It is a W3C standard from 2023, and it carries legal weight in the European Union via EN 301 549, in the United States via Section 508, and in the UK via the Equality Act 2010. When a stakeholder says “the contrast is fine,” the designer can say “WCAG says 4.5:1, and the automated checker sampled a blended pixel; let us test the real text.” The standard is not an opinion; it is a measurable number. The target size is 24 pixels, not “big enough.” The focus indicator is 2:1 against the adjacent background, not “a dashed line.” The standard is the lever that moves a meeting from “I prefer this shade” to “this fails a requirement.”

The Limits of the Rules: When the Standard Is Not the Goal

Every rule has a limit, and the limit is the difference between a craft and a checklist. The WCAG 2.2 target size of 24 pixels is a minimum for a reason: it is the size at which a user with a motor impairment can reliably hit the target, but it is not comfortable. The contrast ratio of 4.5:1 is a floor. A user with low vision will still struggle at 4.5:1 on a dim screen, and the ratio must be verified at the actual rendering size, not at the design size. The baseline grid is a recommendation, not a law. A design with a single line of large text may not need a grid, but a multi-column form does. The type scale from Material Design 3 or Apple HIG is a starting point. A brand with a specific voice may need a display face that sits outside the scale, and that is acceptable as long as the body text stays legible.

The rule that has no limit is the one about states. Every component has a state, and every state has a requirement. A button without a hover state is a guess. A button without a focus state is a barrier. A button without a disabled state is a lie. The list of states is not a design decision; it is a contract between the interface and the user. The designer who can list the states of every component in the system, and the requirements for each state, is not a designer; they are a professional. The one who cannot is a decorator. This is not about decoration; it is about the craft of making interfaces that work for the person who is going to use them, and that means the person who is going to fail them. Design for that person, and the rules become tools. Design for the mock-up, and the rules become excuses.

UI Design Basics Covering Every Interactive State and Accessibility Requirement