Rebuilding a native <button> from scratch: a lesson in why you shouldn't

Web accessibility advice usually starts with two rules: don’t use ARIA if you can avoid it, and always prefer a native HTML element over a hand-rolled one. This piece justifies that advice by walking through what it actually takes to reconstruct something as mundane as a button. Native elements ship with a long list of built-in guarantees, and a custom replacement has to reproduce every one to satisfy WCAG 2.2 — a proper button role and accessible label, keyboard focusability, activation via mouse, touch, stylus, Space and Enter, form participation (type, name, value, validation, reset/submit), disabled and other states, plus hooks for newer platform features like the Popover and Invoker Commands APIs.

The author builds a custom element step by step to show how quickly the complexity compounds. An icon-only button using an emoji, for example, gets announced by screen readers as ‘pile of poo’ and may render as a replacement glyph, so it needs an explicit aria-label plus the emoji hidden as presentational. Making it focusable requires tabindex=“0”; making it activate requires separately wiring mouseup, touchend, and pointerup, then keydown and keyup for the keyboard. Moving the markup into a JavaScript class with ElementInternals and shadow DOM tidies the HTML but adds its own layer of complexity.

The takeaway is that even after all this scaffolding, the reimplementation only reaches parity with what gives you for free — and still owes keyboard handling, form integration, and validation. Recreating native controls is framed, aptly, as a Sisyphean task: the browser has already solved a deceptively large problem, and rolling your own mostly means reintroducing bugs and accessibility gaps that the platform eliminated.