Across a large component library, `<div>`-based controls with hand-written ARIA keep reappearing even though native elements exist for them. How would you make native-first the default, and when is a custom ARIA widget genuinely justified?

## Diagnose before you legislate When the same defect keeps returning after being fixed, education is not the missing input. Ask why an engineer chose a div in the moment. The honest answers are usually structural: - **The styled path is the wrong path.** The design system's `.btn` class was written for a div, or a global reset stripped the native button so thoroughly that it is easier to start from nothing. - **The design forbade the native control.** A picker mock-up that no native `<select>` can render, so the whole control was rebuilt — and then the pattern was copied for controls that *could* have been native. - **The framework primitive encouraged it.** A generic wrapper component that renders a div and spreads props, so the tag is invisible at the call site. - **Nothing caught it.** Review looked at the diff's logic, the automated checker passed, and no one used the keyboard. Each cause has a different fix, and a policy that ignores them produces a rule people route around. ## Make the correct thing the cheapest thing The governing principle: engineers do not choose accessibility, they choose the shortest path. Move the shortest path. **Ship the primitives.** A small, non-negotiable set — button, link, text input with its label, checkbox, radio, select, disclosure — each built on the native element, each fully styled to the design language, each with the focus indicator already correct. If the styled component is the native element, using it is not a virtue, it is the default. **Remove the traps.** Audit the global stylesheet for resets that make native elements unusable and the design constraints that made teams abandon them. This is where a design-system owner earns their keep: negotiating a select that is stylable-enough rather than shipping a hand-built listbox to every product. **Make the exception visible.** A generic box primitive that lets any tag be passed in encourages accidental divs. Require interactive components to name their element explicitly. ## Enforce at the cheapest checkpoint Layer the checks so each catches what the previous cannot: - **Lint** for the syntactic tells: `role` on a generic tag, `tabindex` on anything that is not a documented pattern, a click handler on a non-interactive element, `role` values that duplicate an element's implicit role. Fast, in-editor, no judgment required. - **Automated rule engines** in CI as a floor — they catch invalid roles, unresolved references, missing names. - **Review** carries the part machines cannot: does the declared pattern implement its keyboard contract? A concrete definition of done for interactive work — *Tab to it, operate it with the keyboard, see the focus indicator* — is worth more than a checklist of attributes. - **Tests** that assert computed role, name and state rather than the presence of an attribute string, so replacing a div with a button does not fail the suite and dropping a native element does. ## When custom is genuinely justified Hold two conditions. First, **HTML has no element for the pattern** — tabs, tree views, comboboxes, grids, carousels, drag-and-drop reordering. ARIA exists precisely for this, and refusing to use it is as wrong as reaching for it first. Second, **a native element exists but cannot meet a hard requirement** — a genuine one, verified, not a styling preference that a designer would trade away if told the price. When you accept a custom widget, accept the whole cost: an owning team, an implementation of the full keyboard contract for that pattern, tests at the accessibility-tree level, verification on the assistive technologies you support, and a review each time the platform ships a native replacement. A custom widget is a *product* with a maintenance budget, and the organisation should have very few of them. ## What you measure Avoid rule counts — they reward attribute hygiene and can improve while users stay blocked. Better signals: how many hand-rolled interactive patterns exist outside the library and whether that number falls; whether the top user flows are completable keyboard-only, retested each release; how many `role`/`tabindex` lint exceptions are open and who owns each. Those track the thing you actually care about. ## The point to land Say that recurrence is a systems signal, not an ignorance signal. Fix the incentive — make the native element the styled, documented, lowest-effort choice — then enforce with the cheapest check that can see the defect, and treat the small set of legitimate custom widgets as owned components rather than as markup.