ARIA Implementation Checklist Template

Use `aria-labelledby` when visible text already exists on the page that can serve as the label. It points to another element's `id` and reuses that text. Use `aria-label` when no visible text exists and you need to provide a label that only screen readers will hear. Prefer `aria-labelledby` because it keeps the visible label and the accessible label in sync automatically. When the visible text changes, the accessible name changes with it.

`aria-live="polite"` (or `role="status"`) waits for the screen reader to finish its current announcement before reading the new content. Use this for non-critical updates like search result counts, success messages, and content that has loaded. `aria-live="assertive"` (or `role="alert"`) interrupts the screen reader immediately. Use this only for urgent messages: errors, warnings, and time-sensitive information. Overusing assertive announcements makes the product feel chaotic for screen reader users.

In many cases, no. A `<button>` already has `role="button"` built in. A `<nav>` already has `role="navigation"`. ARIA becomes necessary when you build custom widgets that have no native HTML equivalent: tabs, tree views, comboboxes, and custom menus. The [accessibility compliance template](/templates/accessibility-compliance-template) covers how to audit whether your use of ARIA is necessary or redundant.

Three layers of testing cover ARIA. First, use browser developer tools (Chrome Accessibility panel, Firefox Accessibility Inspector) to verify that ARIA attributes are present and values are correct. Second, use automated tools like axe-core to catch common ARIA errors (invalid roles, missing required attributes, orphaned IDs). Third, test with screen readers (VoiceOver, NVDA) to verify the actual user experience. The [assistive tech testing template](/templates/assistive-tech-testing-template) provides structured test protocols for screen reader verification.

Incorrect ARIA can make a component less accessible than it would be with no ARIA at all. Common problems: `role="button"` on a `<div>` without keyboard event handlers creates a "button" that keyboard users cannot activate. `aria-hidden="true"` on an interactive element makes it invisible to screen readers but still visible and clickable. Stale `aria-expanded` values that do not update when the component state changes mislead screen reader users about the current state. Always test ARIA changes with a screen reader before shipping.