Accessibility prompts: connect form errors and status changes

Last updated: 4 Oct 202611 min read

tutorial

An error-review prompt should pair each failed field with its label, current value state, visible error, programmatic relationship, and focus or announcement behavior. Separate client-side validation from a server response, because each can fail differently. Status text that changes after submission also needs an observable notification path without stealing focus without reason. The model can draft a field-by-field checklist. It cannot establish that a message is heard until the actual interface is tested with its intended assistive technology.

Operational case

Harbor rejects a blank pickup code. The red border is visible, but the input has no text error connected to it. A reviewer records the exact failed-submit state and asks for a repair that exposes a readable message and associates it with the field. After the change, they test keyboard focus, field description, and the server-delay status. The screenshot remains supporting evidence, not the sole pass criterion.

Field: pickup code; state: blank on submit
Observed: red border; no linked text error
Repair target: visible instruction + programmatic association
Retest: focus, field description, server status
Unverified until tested: spoken output

Performance and review cost

Reviewing F fields across E error states costs O(FE) checks in the worst case. A reusable form component can reduce implementation work, but it does not remove the need to test distinct server errors and field combinations. Keep test values synthetic and preserve the response code so a later reviewer can reproduce the same branch.

Common Mistakes

Do not rely on red color as the only error signal.
Do not attach an error message to the wrong field.
Do not treat a visible status as proof that it was announced.

Connected lessons

prompt engineering

accessibility review