Rule 1: Prefer native HTML
If a native element (<button>, <a>, <input type="checkbox">) does what you need, use it. Native elements ship with keyboard behavior, focus management, and screen-reader semantics for free.
Rule 2: Do not change native semantics
Never write <h1 role="button">. If you need a button that looks like a heading, use a real <button> and style it.
Rule 3: All interactive ARIA controls must be keyboard operable
A role="button" on a div requires tabindex="0", an Enter/Space handler, and disabled/pressed state logic. If you can't commit to all three, don't use the role.
Rule 4: Do not use role="presentation" or aria-hidden="true" on focusable elements
Hiding a focusable element from assistive tech but leaving it in the tab order creates a phantom focus stop that confuses everyone.
Rule 5: All interactive elements must have an accessible name
Buttons, links, and form controls need a name — via text content, aria-label, or aria-labelledby. Icon-only buttons are the most common failure.
When ARIA is worth it
ARIA earns its keep for widgets HTML doesn't provide: tabs, tree views, comboboxes, live regions, dialogs pre-<dialog>. Follow the ARIA Authoring Practices Guide patterns exactly — do not invent variations.