Building accessible UI components

Short version: an accessible component works for everyone — people using a keyboard, a screen reader, or a mouse; in bright sun or with low vision. The basics get you most of the way: use real HTML elements, make everything keyboard-operable, manage focus, label things clearly, and ensure enough colour contrast. It's not exotic work — it's careful defaults.

Accessibility isn't a niche feature or a legal checkbox — it's building interfaces that work for the full range of people who'll use them. And most of it comes down to getting the fundamentals of each component right. Here are the practical basics.

Start with real HTML

The single biggest win is using the correct native element for the job. A real <button> is focusable, clickable with the keyboard, and announced as a button by screen readers — all for free. Rebuild it from a plain <div> and you throw all of that away and have to recreate it by hand (usually imperfectly). Reach for semantic HTML — buttons, links, inputs, headings, lists — before anything custom.

Make it work with a keyboard

Many people navigate entirely by keyboard, and screen readers rely on it too. Every interactive element must be reachable with Tab and operable with Enter or Space, in a logical order. If you can't use your component without a mouse, neither can a large group of your users. Test it: put the mouse down and try.

Manage focus and labels

Visible focus. Keep a clear focus indicator so keyboard users can see where they are — never remove it without a replacement.
Move focus sensibly. When a dialog opens, move focus into it; when it closes, send focus back. Don't leave people lost.
Label everything. Inputs need real labels, icon-only buttons need accessible names, and images need alt text. A screen reader can only announce what you've labelled.

Mind colour and contrast

Text needs enough contrast against its background to be readable — for users with low vision and for everyone squinting at a phone in sunlight. And never rely on colour alone to convey meaning (like a red field for an error); pair it with text or an icon so the message survives for colour-blind users.

Accessibility isn't extra work bolted on at the end — it's what "built correctly" means.

Key takeaways

Use real, semantic HTML elements before building custom ones.
Make every component fully keyboard-operable in a logical order.
Keep focus visible and managed; label inputs, buttons and images.
Ensure sufficient contrast, and never rely on colour alone.

Frequently asked questions

What is the easiest way to make components accessible?

Use the right native HTML elements. A real button, link, or input comes with keyboard support, focus behaviour and screen-reader meaning built in. Most accessibility problems come from rebuilding these with plain div elements and forgetting what you lose.

Do I need to test with a screen reader?

It helps a lot. Automated tools catch some issues, but actually navigating your component with a keyboard and a screen reader reveals problems no checker will. It's the single best way to understand the experience you're shipping.

Is accessibility only for users with disabilities?

No — accessible design helps everyone. Keyboard support aids power users, good contrast helps in bright sunlight, clear labels help all of us. Building for the full range of users produces a better product across the board.

ZIVARA builds interfaces that are accessible by default — usable by everyone, on any device. Let's talk. Related: why accessibility is good business.