Accessibility Is a Design Skill, Not a Checkbox

For years I treated accessibility as something to fix at the end. That was a mistake. I would design a beautiful set of screens, hand them off, and then, a week before launch, someone would run an audit and send back a long list of problems: low contrast, missing labels, buttons too small to tap, forms that made no sense to a screen reader. We would patch what we could, ship the rest, and promise to do better next time.

Designing for everyone from day one makes products better for all of us. It took me an embarrassingly long time to understand that accessibility is not a separate discipline bolted onto design. It is design. It is the craft of making something clear, usable and forgiving for real people in real conditions. Here is how my approach changed, and the habits I now build into every project from the first sketch.

Start with contrast

Text that’s easy to read in sunlight is easier for everyone. That single sentence changed how I choose colors.

Light gray text on a white background looks elegant on a big, bright monitor in a dim studio. It falls apart on a phone at a bus stop at noon, on an older laptop with a dull screen, or for anyone whose eyesight is less sharp than it used to be. Which, eventually, is all of us.

These days I check contrast while I pick the palette, not after. The widely used accessibility guidelines recommend a contrast ratio of at least 4.5 to 1 for normal body text and 3 to 1 for large text and key interface elements. I keep a contrast checker open the whole time I work, and I build the minimum ratios directly into the color tokens of the design system so no one has to remember them.

Contrast is not only about text. Icons, input borders, focus rings and the edges of buttons all need to stand out from what is around them. A form field defined by a faint hairline border is a form field many people simply will not see.

When you design for the edges, the middle takes care of itself.

Owen

That is the idea I keep coming back to. When you design for someone with low vision, the high-contrast result also helps the person with perfect eyesight squinting at a phone in bright light. When you design for someone using only a keyboard, you also help the power user who never wants to touch a mouse. The edge cases turn out to be everyday cases in disguise.

Big tap targets

Forty-four pixels minimum. Thumbs are not precise instruments.

I learned this watching usability sessions. People would try to tap a small link, miss, hit the one next to it, and end up somewhere they never meant to go. Then they would blame themselves. It was never their fault. It was mine, for putting two tiny targets right next to each other.

Now I treat roughly 44 by 44 pixels as the floor for anything tappable, and I leave space between targets so a slightly off tap does not trigger the wrong action. The visible button can be smaller if the design needs it, but the actual touch area should not be. This matters even more for people with tremors, limited dexterity or larger hands, and it helps anyone using a phone one-handed while holding a coffee or a child.

Places I check first

• Close buttons on dialogs and banners, which are almost always too small
• Icon-only actions in toolbars and table rows
• Links inside dense paragraphs of text
• Checkboxes and radio buttons, where the label should be tappable too
• Pagination and carousel dots

Focus states you can see

Many people navigate with a keyboard, a switch device or a screen reader rather than a mouse. For them, the focus state, the visual outline that shows which element is active, is the cursor. If you remove it because it looks untidy, you have removed the only thing telling them where they are.

I design focus states on purpose now, the same way I design hover and pressed states. They get a clear, high-contrast outline that matches the brand and never disappears. I also walk through every prototype using only the Tab key before I call it done. It takes ten minutes and almost always turns up something: a menu you cannot close, a modal that traps focus, or a tab order that jumps around the page in a confusing sequence.

Words do half the work

Accessibility is not only visual. Clear writing is one of the most powerful accessibility tools a designer has, and it costs nothing.

Buttons should say what they do: “Save changes,” not “Submit.” Links should make sense out of context, because screen reader users often jump from link to link. “Read the pricing guide” works; “click here” does not. Error messages should explain what went wrong and how to fix it, in plain language, right next to the field that caused it.

I also write alt text for images while I design, not after. If an image carries meaning, the description should carry that same meaning. If it is purely decorative, it should be marked that way so screen readers skip it. Writing alt text early has an unexpected side effect: it makes me ask whether an image is actually needed at all.

My quick writing checklist

1. Every button label is a verb that describes the result
2. Every form field has a visible label, not just placeholder text
3. Every error message says how to fix the problem
4. Every meaningful image has a short, specific description
5. Headings form a logical outline of the page

Making it a habit

The biggest change was not any single technique. It was moving accessibility from the end of the process to the beginning. On my projects today, accessibility notes are part of every component spec. Contrast ratios live in the color tokens. Focus states ship with the first version of every button. And every round of user research includes at least one participant who uses assistive technology or has different access needs.

That last point matters most. Guidelines and checkers are useful, but they do not replace watching a real person use what you made. Some of the most important fixes I have ever shipped came from a single session with someone using a screen reader, who calmly showed me in five minutes what three audits had missed.

Key takeaway: Accessibility is cheaper, faster and better when it starts in the first sketch. Treat it as a design skill you practice daily, not a checklist you run once before launch.

Better for everyone

I still make mistakes. I still catch a low-contrast label or a tiny icon button in my own work. The difference is that I catch them on day three instead of day ninety, when fixing them takes minutes instead of a sprint.

If you are just starting, pick one habit from this post and use it on your next project. Check contrast as you choose colors, or walk through your prototype with only a keyboard. Once you see how much clearer your work becomes, you will not want to design any other way.