Accessibility Is Just Good Design

You have been told accessibility is a compliance burden. A checklist someone in legal forces on you right before launch, a tax on shipping, a pile of ARIA attributes you bolt on to avoid getting sued. So you defer it, you ship without it, and nothing bad seems to happen — for a while.

Here is the reframe that changes everything: the work that makes your product usable for a blind user is the same work that makes it better for everyone. Captions help the deaf user and the person on a muted phone in a loud train. High contrast helps the low-vision user and the person squinting in direct sunlight. Keyboard support helps the motor-impaired user and the power user who never touches the mouse. This is the curb-cut effect — the ramp cut into the sidewalk for wheelchairs turns out to help the parent with a stroller, the traveler with a suitcase, the worker with a dolly.

The engineers who get this stop treating accessibility as a separate phase and start treating it as a quality signal, the same way they treat a passing test suite. The rest of this chapter is the small set of moves that buy the most accessibility per unit of effort — and, not coincidentally, the most polish.

The trap: compliance thinking makes worse products

When you treat accessibility as compliance, you do the minimum to pass an audit and you do it last. You bolt aria-label onto everything, including elements that never needed it. You add a skip-link nobody tests. You "fix" contrast by running an automated checker and nudging hex values until the tool goes quiet, with no thought to whether the result still looks like your product.

Compliance thinking produces interfaces that pass the audit and still feel broken to the people the audit was meant to protect. It is the accessibility equivalent of writing tests that pass without testing anything real.

The shift is from "what do I have to add to pass" to "what did I already break that I can stop breaking." Most accessibility failures are not missing features. They are things you actively did — removed the focus ring, used color alone, nested six divs where a button belonged — that you can simply stop doing.

Contrast: the failure you can measure

Contrast is the best place to start because it is the most common failure and the only one you can put a number on. Low-contrast text is everywhere in developer-built interfaces: the gray-on-gray timestamp, the placeholder doubling as a label, the "subtle" helper text nobody over forty can read.

It happens because you test on a brand-new high-resolution display at full brightness, ten inches from your face, with young eyes. Your user is on a three-year-old laptop at half brightness in a sunlit room. The contrast that looks elegantly subtle to you is invisible to them.

Three numbers cover almost everything you will face. Normal text needs a contrast ratio of at least 4.5:1 against its background. Large text — roughly 24px and up, or 18.66px bold — drops to 3:1. And non-text essentials like icon strokes, input borders, and focus rings also need 3:1, because a control you cannot see is a control you cannot use.

The fastest way to internalize this is to stop trusting your eyes and start reading numbers. Every browser's devtools shows a contrast ratio right in the color picker, and your design tokens should record it. Bake the ratio into the token comment so it travels with the value:

:root {
  /* text on white — 4.5:1 minimum for body */
  --text-primary:   #1a1a1a; /* 16.1:1  AAA  */
  --text-secondary: #595959; /* 7.0:1   AAA  */
  --text-muted:     #6b6b6b; /* 5.7:1   AA   */
  --border-subtle:  #d4d4d4; /* 1.5:1   decorative only — never text */
}

That comment column is doing real work. The moment a teammate reaches for --border-subtle as a text color, the note warns them it will fail. You have turned an invisible rule into a visible one that lives in the code — the same move as the contrast discipline behind your 60-30-10 palette.

Color is not the only channel

The second-most-common failure is leaning on color alone to carry meaning. The red field is invalid; the green badge is active; the chart's blue line is revenue and the orange line is cost. To roughly one in twelve men, those pairs are indistinguishable, and to a screen reader they do not exist at all.

The rule is simple: color may reinforce meaning, but it must never be the only thing carrying it. Pair it with a second channel — an icon, a label, a shape, a position.

This is not a niche concern. Color-blind users are a larger share of your audience than the users of some browsers you happily support. You would never ship something broken in Safari; do not ship something broken for one in twelve men.

The grayscale pass from the Squint Test chapter is your check here too. Drop the whole screen to grayscale; if any status, state, or category becomes ambiguous, color was doing work it should have shared.

Keyboard and focus: the cursor is not the only way in

A huge share of accessibility is simply this: everything you can do with a mouse, you must be able to do with a keyboard. Power users live on the keyboard. So do people with motor impairments who cannot use a trackpad, and people using switch devices or voice control that maps to keyboard events.

The most common accessibility crime developers commit is a single CSS line: outline: none. You remove the focus ring because it looks ugly on click, and in doing so you blind every keyboard user — they can no longer tell where they are on the page. The fix is not to delete the focus state but to design one you are proud of, and to scope it to keyboard users with :focus-visible so it never shows on a mouse click:

*:focus-visible {
  outline: 2px solid var(--color-primary);
  outline-offset: 2px;
  border-radius: 3px;
}

A visible focus ring is a feature, not a blemish. Two more keyboard rules earn their keep. First, tab order must follow reading order — if Tab jumps around the screen at random, your DOM order and visual order have diverged and need to be reconciled. Second, give controls a comfortable hit area: the web target-size guidance lands at 24px, but the 44px target borrowed from touch design is the gold standard, and bigger targets help everyone, not just the user with a tremor.

Semantics: the browser already does the work for you

Here is the part that should make a developer happy, because it is less work, not more. Most screen-reader support is something you get for free by using the right HTML element — and lose the moment you reinvent that element with a div.

The rule of thumb: if it navigates, it is a link; if it acts, it is a button. Never make a div do either's job. A real button is focusable, fires on Enter and Space, announces itself as a button to a screen reader, and participates in forms — all behavior you would otherwise have to rebuild by hand, badly. The same logic that says each view gets One Primary Action also says that action should be a real button element, not a clickable div pretending to be one.

Beyond using the right elements, three habits cover most of the remaining ground: every image that carries meaning gets alt text (and every decorative one gets empty alt=""), every form input gets a real associated label, and headings describe the actual structure of the page rather than being chosen for their size. Reach for ARIA only when no native element fits — the first rule of ARIA is to not use ARIA when HTML already says it.

None of this is exotic. It is the same instinct that drives every other chapter in this book: stop shipping the rough version of the thing a real user will hit. Done this way, accessibility stops being a separate burden and folds into the Polish Checklist — one more pass that quietly raises quality and, like everything visible, pays down the Competence Tax.

What to do Monday morning