Native vs Custom: When to Reach for a Real Element

For any control you face one choice: use a native HTML element or hand-build a custom one. Native almost always wins.

A native button is focusable, clickable by mouse, keyboard, and touch, and announced correctly. You write one tag and the platform does the rest.

Style a span to look like a button and it still has no role, no focus, and no keyboard support. It only fools the eye.

To make a custom control work you must add a role, tabindex, and key handlers for Enter and Space. That is a lot of code to match one tag.

Even careful custom controls miss edge cases: focus rings, disabled states, touch. The native element already handles every one of them.

This holds for the whole platform. A real select, checkbox, or details gives you behavior and accessibility that a div imitation never fully matches.

Native form controls submit with the form, validate themselves, and pair with a label automatically. Rebuilding that by hand is rarely worth it.

Go custom only when no native element exists for the pattern, like a tabbed interface or a tree. Then follow a proven authoring pattern carefully.

Worried a real button looks plain? You can style native elements heavily with CSS. Keep the semantics, change the skin to anything you like.

Reaching for the real element means less JavaScript, fewer bugs, and a control that survives browser and assistive tech updates for free.

Make it your default: native first, custom only as a last resort. The web platform is a huge accessibility gift, so let it do the work.

Let us decide native or custom.

Choose native first: a real button or input gives you focus, keys, and semantics for free. Go custom only when no element exists, and style native freely. 🎉