a11y patch agent failed on dynamically injected aria-live region
Fixes patch agent failures on dynamic aria-live regions by patching the region's creator instead of the node. Use it when live region patches vanish on rerender. Not for static live regions, where DOM patches stick.
a11y patch agent failed on dynamically injected aria-live region - how to fix it
TL;DR
Patch the live region's creator, not the region: dynamically injected aria-live regions get wiped on the next render, so the agent must fix the component or script that creates them. Re-applying attributes to a node that will be replaced is futile. One line of why: the region is ephemeral, its creator is persistent, and patches must target what persists.
The error, verbatim
RemediationAgentError: live region patch lost on rerender
patched: aria-live=polite on #toast-region
after_rerender: node replaced, attributes gone
framework: toast library recreates region per message
Fix it step by step
Step 1: Reproduce the lost patch
node agent/remediate.js --rule aria-live | rg -i 'lost|rerender|replaced' | head -5Expected: The patch applies then vanishes on the next render.
Step 2: Find the region creator
rg -n 'aria-live|toast' src --glob '*.{jsx,tsx,js}' | head -10Expected: Shows the toast library or component creating the region.
Step 3: Patch the creator
rg -n 'live' agent/patches/aria-live.js | head -10Expected: Change the patch target from the DOM node to the creator's config or source.
Step 4: Re-run remediation
node agent/remediate.js --rule aria-live | tail -4Expected: Region is created correctly and survives rerenders.
Step 5: Add a regression probe
node agent/run-audit.js --smoke | tail -3Expected: Smoke run passes; schedule it so the breakdown is caught if it ever regresses.
When to use this skill
- You run an agent that scans UIs for accessibility and it hits this breakdown
- The agent's scan loop stalls, crashes, or loops on this exact failure
- You are hardening an audit agent's error handling for production scans
When NOT to use this skill
- A human runs the scan manually and it works, this is agent-harness failure handling
- The scan completes and only reports violations, use the rule-specific skills
Compatibility
Remediation agent with source patch ability. Toast and notification libraries are the usual creators. Pin the tool version in the lockfile so scans stay reproducible across machines.
Variant phrasings
agent live region patch overwritten
Same loss, same creator-level fix.
aria-live injected dynamically remediation
Practitioner phrasing.
the breakdown hits other routes too
Agent failure modes are systemic; apply the hardening to every route the agent covers, not just the one that failed.
Why it happens
Toast libraries and notification systems create aria-live regions dynamically per message, replacing the node each time. An agent patching attributes on the live node watches its work evaporate on the next toast. The durable patch configures the creator: the library's options, the component's props, or the template that emits the region. This is the same lesson as the label rerender loop: patch what persists, not what renders. Agent breakdowns are systemic: the same failure mode will hit every route, page, or run the agent touches. Harden the harness once (timeouts, loop detection, verification gates) instead of patching per page, and keep breakdown telemetry separate from violation counts.
Edge cases
- Some libraries expose no config for the live region, then the fix is a wrapper component or a library swap.
- Assertive vs polite is a product decision, the agent should preserve the intended politeness, not upgrade it.
- Verify across two toast cycles, one render is not proof the patch sticks.
- Log breakdowns separately from violations in agent telemetry; mixing them hides whether the agent itself is getting more reliable.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_nxdFuehq2d8RSnWK5GG8IQ