A capability stays maintainable only when the team can explain every state, retry, and piece of residual data—not merely show one successful run. Unknown error gives no recovery, while ICE 701 is engineer-only. Start with task impact, such as file not sent but safely retained for retry.
Accessibility is not a late set of ARIA attributes. Keyboard, screen-reader, zoom, reduced-motion, and high-contrast users need the same complete task and a discoverable next step after errors.
Questions the design must answer
Turn the important choices into durable contracts: validate inputs, assign state ownership, define cleanup, and specify fallback for older peers. Later optimization must not change those semantics.
- Errors expose summary, impact, action label, and optional details, move focus once to the summary without repeated theft, and place requestId in disclosure.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Retries need an idempotency key, backoff, and deadline; after the deadline create a new task instead of reviving old callbacks.
The delivery standard for Accessible Error Recovery Language Explains Impact and Next Action is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Edge cases are part of the feature
An abnormal path is more than an error banner. It decides how in-flight work stops, how the peer learns the outcome, what residue remains, and whether the next operation inherits it.
- Reading raw stacks is noisy and unsafe, while red borders without field associations leave users unable to locate problems.
- A boolean failure cannot distinguish retryable, user-action, and permanent refusal, producing an endless loop.
- An untested fallback receives all traffic during a primary failure and becomes the slower, more expensive bottleneck.
Prove that it works with evidence
Do not stop verification when the final action succeeds. Count side effects, measure wait time, inspect privacy, and prove the next run begins from a clean baseline.
- Have screen-reader and cognitive-access users recover from ten error classes; measure impact comprehension, first-action success, focus return, and repeats.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Cover direct, relayed, weak-network, background-tab, and mobile paths; do not rely on averages or one successful screenshot.
The release bar is clear: users understand the current state, failures stop or recover, resources stay bounded, and operators can identify the phase from minimum necessary evidence.