arrow_back Index

The Button

also known as: The Primary Action, The CTA, The Trigger, The Div-That-Looks-Like-A-Button

Threat Level
★★★★
"It was a div. It looked like a button. It had a click handler. But when I pressed Space, nothing happened. When I pressed Enter, nothing happened. When the screen reader arrived at it, it said nothing. I pressed it anyway. I do not know what I pressed."

From the incident log of the Accessibility Audit, Third Quarter, author unknown, tone unmistakeable

The Button is the most elemental creature in the Codebase — the primitive from which all interaction flows. Every dungeon contains them. They are the oldest and most recognisable members of the interactive fauna, and they are, paradoxically, among the most frequently implemented incorrectly. The specific manner of their misimplementation has remained consistent across two decades of field observation: the div-that-looks-like-a-button, which possesses the visual characteristics of the Button without its native properties, is the Codebase's most prolific imposter.

The genuine Button — the native <button> element — arrives pre-equipped with capabilities its imitators lack: keyboard activation via both Space and Enter, correct focus handling, an implicit ARIA role of "button" readable by all assistive technology, disabled state management, and form submission behaviour where applicable. It is provided by the browser at no charge. The div-based alternative must manually replicate each of these properties through JavaScript and ARIA attributes, at considerable effort, and almost never fully succeeds.

Fig. VIII — Three Button specimens: Primary (filled, confident, focus ring visible), Secondary (outlined, deferential), Ghost (dashed, barely committed). Below: Disabled (grey, inert) and Loading (spinner, patient).

The Button's internal hierarchy — Primary, Secondary, Ghost, Destructive, Disabled — represents a vocabulary of intent that, when applied consistently, guides users through the dungeon with clarity. A page with seven Primary Buttons has no Primary Button; it has seven equally weighted options competing for attention. The hierarchy exists to create a single clear path forward. When summoners abandon this principle, the dungeon offers no clear path forward, and the user, faced with seven identical choices, makes none.

swords Vital Statistics

STR12(+1)
DEX16(+3)
CON15(+2)
INT10(+0)
WIS13(+1)
CHA18(+4)

auto_awesome Special Abilities

Native Activation (Passive). The genuine Button responds to click, Space, and Enter without implementation effort. It manages its own focus styles, announces itself correctly to screen readers, and disables gracefully when the disabled attribute is applied. These properties are not achievements — they are the baseline. They are only remarkable because so many imposters lack them.
Minimum Target Size (Passive). The Button requires a minimum interactive area of 44×44px as mandated by WCAG 2.5.5. The visible button may be smaller; the clickable region must not be. Buttons that are 32px tall and 80px wide are failing half their users. Padding exists for a reason. The reason is fingers.
Loading State (Action). When the action triggered is asynchronous, the Button should communicate the in-progress state visually (via spinner or label change) and functionally (by disabling re-activation). A Button that can be pressed multiple times during a loading state has surrendered its authority over the action it governs.

shield Weaknesses

  • The native <button> element — eliminates the div-imposter problem entirely and at no additional cost
  • Clear labels — "Save changes", "Delete account" defeat the Button; "OK" and "Click here" do not
  • One Primary per context — the creature cannot assert dominance while sharing its category with six siblings
  • 44dp minimum touch target — on mobile, a Button smaller than this will be missed by users with typical finger precision

category Known Variants

  • The Primary Button — filled, high contrast, one per context. The hero. Overused to the point of meaninglessness in many dungeons.
  • The Secondary Button — outlined or lower-contrast. Accompanies the Primary without competing with it.
  • The Destructive Button — red-coded, guards irreversible actions. Should always appear alongside a Cancel option.
  • The Icon Button — label replaced by a glyph. Requires an accessible name via aria-label. Often lacks one.
  • The Link-styled Button — visually a link, semantically a button. Taxonomically distressing. Sometimes correct.

edit_note Field Notes

Note I. — If the element navigates the user to a new location, use an anchor (<a>). If it performs an action, use a button (<button>). This distinction is not stylistic. It is the entire semantic contract between the interface and its users.

Note II. — Never disable a Button without explaining why. A disabled Button with no tooltip or explanation tells the user that something is wrong without telling them what. This is not helpful. It is the absence of help wearing help's clothing.

Note III. — The label of a Button is a promise. "Save" promises the data will be saved. "Submit" promises the form will be submitted. Name your Buttons after their consequence, not their mechanism.

The Component Bestiary · Vol. I · Entry VIII — The Button