# Live Regions

Announce dynamic content changes to screen readers.

## Criteria

| Standard | Criteria                   |
| -------- | -------------------------- |
| WCAG 2.2 | 4.1.3 Status Messages (AA) |
| RGAA 4.1 | 7.5 Status messages        |

### Status Messages — WCAG 4.1.3 (AA) / RGAA 7.5

Status messages must be announced to assistive technologies without receiving focus. Use `role="status"` with `aria-live="polite"` for general updates. Use `role="alert"` with `aria-live="assertive"` for errors. Use `role="log"` for chat/history. Use `role="progressbar"` or `aria-busy` for loading states.

### RGAA 7.5 — Status messages correctly rendered by assistive technologies (Level AA)

Are status messages correctly rendered by assistive technologies?

#### Test 7.5.1 — Success/result/state messages use `role="status"`

Does each status message informing of success, result of an action, or application state use `role="status"`?

Methodology:

1. Find status messages in the document.
2. For each message, determine the nature of the information it carries:
3. If the message informs of success, result of an action, or application state, verify the containing element:
   - Either uses `role="status"`;
   - Or uses `aria-live="polite"` and `aria-atomic="true"`.
4. If the message presents a suggestion or warns of an error, verify the containing element:
   - Either uses `role="alert"`;
   - Or uses `aria-live="assertive"` and `aria-atomic="true"`.
5. If the message indicates process progression, verify the containing element:
   - Either uses one of `role="log"`, `role="progressbar"`, or `role="status"`;
   - Or uses `aria-live="polite"` if the intent is to signal the equivalent of a `log` role;
   - Or uses `aria-live="polite"` and `aria-atomic="true"` if the intent is to signal the equivalent of a `status` role.
6. If so, the test is validated.

#### Test 7.5.2 — Suggestion/error messages use `role="alert"`

Does each status message presenting a suggestion or warning of an error use `role="alert"`?

Methodology: Same as test 7.5.1 (steps apply to suggestion/error messages specifically).

#### Test 7.5.3 — Progress messages use `role="log"`, `role="progressbar"`, or `role="status"`

Does each status message indicating process progression use one of `role="log"`, `role="progressbar"`, or `role="status"`?

Methodology: Same as test 7.5.1 (steps apply to progress messages specifically).

#### Notes techniques

The WAI-ARIA roles `log`, `status`, and `alert` implicitly carry `aria-live` and `aria-atomic` values. Per WAI-ARIA 1.1:

- `aria-live="polite"` on a status message can serve as a `log` role;
- `aria-live="polite"` + `aria-atomic="true"` on a status message can serve as a `status` role;
- `aria-live="assertive"` + `aria-atomic="true"` on a status message can serve as an `alert` role.

This is valid only when the nature of the status message matches the implicit correspondence. For a progress message rendered as a progress bar, an explicit `role="progressbar"` is required.

#### WCAG references

- 4.1.3 Status Messages (AA)

## Patterns

```html
<!-- Polite: waits for pause in speech -->
<div aria-live="polite" aria-atomic="true">3 items in cart</div>

<!-- Assertive: interrupts immediately (errors only) -->
<div aria-live="assertive" role="alert">Payment failed. Please try again.</div>
```

**Alpine.js:**

```html
<div x-data="{ count: 0, msg: '' }" x-init="$watch('count', v => msg = `${v} items`)">
  <p aria-live="polite" class="sr-only" x-text="msg"></p>
</div>
```

Rules:

- `aria-live="polite"` for most updates (cart count, status messages, search results)
- `aria-live="assertive"` only for errors and time-sensitive alerts
- Region must exist in DOM before content changes — don't dynamically insert the region