aria-usagelisted

# ARIA usage ARIA adds accessibility semantics where HTML falls short, and its first rule is a warning: do not use ARIA if a native element does the job. Most broken ARIA comes from adding it where it was not needed or adding roles without the keyboard behavior and state management they require. Native first, ARIA carefully. ## Method 1. **Prefer native HTML elements (the first rule of ARIA).** A `<button>` is accessible for free: focusable, keyboard- operable, announced as a button. A `<div role="button">` requires you to add tabindex, keyboard handlers, and states manually, and you will miss some. Use `<button>`, `<a>`, `<input>`, `<select>`, `<nav>`, `<main>` before reaching for ARIA: native semantics beat reimplemented ones every time. 2. **Understand roles, states, and properties.** Role (what it is: `role="tab"`), states (current condition, dynamic: `aria-selected="true"`, `aria-expanded="false"`), properties (characteristics, mostly static: `aria-label`, `aria-controls`). A role sets expectations the rest of the ARIA and the keyboard behavior must fulfill; `role="tab"` promises tab behavior you must then deliver. 3. **Follow the established widget patterns.** For custom widgets (tabs, menus, comboboxes, dialogs, tree, accordion), the ARIA Authoring Practices Guide defines the exact roles, states, and keyboard interactions expected: implement the whole pattern, not a subset. Half-implemented patterns (a role wi