UI release prompts: compare appearance and verify access

Last updated: 5 Oct 202611 min read

tutorial

A UI release prompt should demand evidence from the rendered implementation, not a confident description of its appearance. Capture agreed states at representative widths, compare them with the approved visual intent, and inspect differences that matter to the task. Then run separate behavior and accessibility checks: keyboard reachability, visible focus, control names, reading order, and status feedback. A screenshot can detect a clipped label but cannot prove a filter works or a screen reader receives an update. Record which states were tested, what failed, what was fixed, and which limits remain. The person responsible for release decides whether the evidence is sufficient.

Operational case

The Dispatch Queue release packet includes wide All at 47, narrow Held at 6, a true empty search, and a request error. Visual review finds a clipped destination in narrow Held and the implementer fixes wrapping. Keyboard review then finds that the custom Retry control has no visible focus; the implementer changes it to a named button using the existing focus style. A scripted state check confirms the error cannot display '0 shipments' as though the server returned a valid empty list. The reviewer records both fixes and approves only after the rendered states are recaptured.

Evidence: wide All 47; narrow Held 6; empty; error.
Visual: no clipped label or hidden action.
Behavior: filter changes count; Retry requests data again.
Access: named controls, reading order, keyboard focus visible.
Release: attach failures, fixes, recaptures, and unresolved limits.

Performance and operating cost

For R rendered states and P pixels per capture, visual review is about O(RP) pixel work plus human inspection. Interaction and access checks add actions per state; they should target observable risk, not try to prove every possible combination. Keep screenshot baselines in a stable rendering environment, because platform font and browser differences can create noise unrelated to a code regression. Automated checks reduce routine misses but do not replace manual keyboard and reading-order review.

Common Mistakes

Do not treat matching pixels as proof of correct keyboard behavior.
Do not treat a successful click as proof that a control has a usable name or focus state.
Do not publish a release packet that omits known failures or untested states.

Connected lessons

Continue with: Accessibility prompts: identify the tested page state.

prompt engineering

ui engineering