Dynamic content updates are announced to screen readers

When a form validation error appears as inline red text, or a toast notification slides in from the corner, screen reader users receive no indication that anything has changed — their focus is still on the input field or wherever it was when they triggered the action. This is a silent failure from the assistive technology's perspective. WCAG 2.2 SC 4.1.3 (Status Messages) requires that status messages be programmatically determinable by assistive technology without receiving focus. SC 1.3.1 (Info and Relationships) covers the relationship between an error message and its field. Section 508 2018 Refresh 502.3.14 requires that changes in status be programmatically determinable. The practical consequence: screen reader users submit forms with errors and receive no feedback, cycling through submission repeatedly with no understanding of why the form fails.

Wrap dynamic content — form errors, success toasts, loading states, live counters — in an aria-live region. Place the container in the DOM before content appears; adding aria-live after the fact does not work reliably.

// Error summary that receives focus on submission failure
{hasErrors && (
  <div
    id="error-summary"
    role="alert"
    aria-live="assertive"
    tabIndex={-1}
    ref={errorSummaryRef}
  >
    <h2>Please fix the following errors:</h2>
    <ul>
      {errors.map(e => <li key={e.field}>{e.message}</li>)}
    </ul>
  </div>
)}

// Polite announcements for non-urgent updates
<div aria-live="polite" aria-atomic="true">
  {statusMessage}
</div>

// Associate field-level errors with inputs
<input
  id="email"
  type="email"
  aria-invalid={!!errors.email}
  aria-describedby={errors.email ? "email-error" : undefined}
/>
{errors.email && (
  <p id="email-error" role="alert">{errors.email}</p>
)}

Use aria-live="assertive" only for urgent errors that interrupt the user. Use aria-live="polite" for status updates that can wait for a natural pause.