The accessibility requirements that are design decisions

Not all of it is engineering

Contrast and target size have already appeared, because they are colour and spacing decisions. Several other accessibility requirements are equally design decisions rather than implementation details, and they are the ones most often discovered late.

Focus has to be visible

Every interactive element needs a visible indication when it has keyboard focus. Without it, somebody navigating by keyboard — because of a motor impairment, because they use a screen reader, or because they are fast at forms — has no idea where they are.

The common cause of failure is a single declaration:

:focus { outline: none; }   /* removes the indicator and provides nothing */

This appears in a great many stylesheets because the default outline was considered ugly. The correct move is to replace it, not remove it:

:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 2px;
}

:focus-visible is the important part: it applies the indicator for keyboard focus and not for mouse clicks, which removes the original aesthetic objection entirely. The indicator itself needs 3:1 contrast against what is behind it, under the non-text contrast criterion.

Zoom and reflow

Two separate requirements, often confused.

1.4.4 Resize Text (AA) — text must be resizable to 200% without loss of content or function. A layout with fixed-height containers and text in pixels fails this, because the text grows and the container does not.

1.4.10 Reflow (AA) — content must be presentable at a width equivalent to 320 CSS pixels without requiring scrolling in two directions. In practice this means 400% zoom on a 1280-pixel screen, and the test is exactly that: zoom a desktop browser to 400% and see whether you have to scroll sideways to read a line.

The design consequence is that a page has to genuinely reflow rather than merely shrink. A fixed two-column layout with a sidebar fails; a layout that stacks fails nothing. Anyone who has built the phone layout properly has already satisfied most of this, which is another argument for designing small first.

Visual order and DOM order must agree

Keyboard focus moves through the document in source order. CSS can reorder elements visually with order, row-reverse, grid-area or absolute positioning — and when it does, the focus order no longer matches what is on screen.

The result is a keyboard user tabbing from the top of the page to something in the middle, then back to the top, with the focus ring apparently jumping at random. It passes every visual review, because visually nothing is wrong.

The rule: if you reorder visually, reorder the source to match. Reordering is fine as a responsive convenience when the two orders agree at every breakpoint; it is a defect when they do not.

Placeholders are not labels

A form field whose only label is placeholder text has three problems: the label disappears as soon as the user types, so nobody can check what they entered; placeholder text is usually low-contrast by default and frequently fails the contrast requirement; and assistive technology handling of placeholders is inconsistent.

Every field gets a visible, persistent label. The floating-label pattern, where the placeholder moves up and becomes a label on focus, is an acceptable compromise; a field with nothing above it is not.

While you are there: the label must be clickable and tied to the field, which doubles the target size for free.

Alt text describes function, not appearance

An image's alternative text should convey what the image is doing in the page.

• A photograph illustrating an article: describe what it shows, briefly.
• A logo that links home: the alt text is the site name, because that is its function.
• An icon inside a button that already has visible text: alt="", because the icon is redundant and announcing it twice is noise.
• A purely decorative image: alt="", which tells assistive technology to skip it entirely.
• A chart: the alt text cannot carry the data. Provide the figures nearby, as a table or a summary sentence.

The commonest error is not missing alt text but unhelpful alt text — image, photo, the file name — which is worse than nothing because it cannot be skipped.

Automated tools find a minority

Be honest about this. Automated accessibility checkers — Lighthouse, axe, WAVE, all free — reliably catch missing alt attributes, contrast failures, missing form labels and some structural problems. Published estimates of their coverage vary and commonly land around a third of issues, and the tools' own documentation says as much.

They cannot tell you whether alt text is meaningful, whether the focus order makes sense, whether an error message is actionable, or whether the interface is usable with a screen reader. That needs a person, and the screen readers are free: NVDA on Windows, VoiceOver built into macOS and iOS, TalkBack on Android, Orca on Linux.

Spending twenty minutes navigating your own product with the keyboard alone, and another twenty with VoiceOver or NVDA, finds more than any audit tool will.