The empty form is the least informative screenshot

An agent produces a clean registration form. Its typography, spacing and button color match the homepage. The default screenshot looks finished, but it does not show whether someone can recover from a rejected field or tell whether a submission completed.

Our recommendation is to review a form as a sequence of user decisions, not a static composition. The decisive question is whether a person understands what is being requested, what went wrong and what to do next without losing useful work.

Methodology and scope

This guide is based on three W3C Web Accessibility Initiative tutorials covering labels, validation and notifications, reviewed on September 11, 2026. It offers a proposed review workflow for product teams evaluating agent-generated forms.

We did not test a specific website, conduct a screen-reader study or certify conformance. The walkthrough below is intentionally narrower than a full accessibility audit. It complements visual design review and backend testing rather than replacing either.

Begin with names that survive interaction

The WAI labeling tutorial recommends labels that describe controls and are programmatically associated with them. It explains explicit association using a label's for attribute and the control's matching id.

During review, enter a value and then return to the field. Can the user still identify its purpose? Does an example format remain available where needed? A short hint inside an empty field should not carry the entire burden of explaining a control.

Our practical recommendation is to keep the visible label, accessible name and error wording aligned. If the field is called Work email, an error referring only to identifier makes recovery harder. For a repeated group, such as multiple contacts, make the surrounding context distinguish the instances instead of repeating an ambiguous label without context.

Separate validation from business decisions

The WAI validation tutorial distinguishes client-side assistance from server-side validation. Browser checks alone do not provide security, and custom validation must notify users accessibly.

For a product review, classify failures before writing messages. A missing required value, an invalid format, a server-side business rejection and a connection failure need different responses. The user should not be told to reformat a field when the actual problem is that the service is unavailable.

Our recommended handoff includes examples of each error category and a named owner for its wording. Avoid displaying raw backend exceptions. Preserve non-sensitive inputs when recovery is possible, but decide separately how passwords or other sensitive fields should be handled. Retention is a product and privacy decision, not an automatic consequence of making a form convenient.

Give errors a recovery route

The WAI notification tutorial discusses overall feedback and messages near individual controls. Its error-list guidance includes identifying the relevant field, explaining the issue and providing a route to that control.

Use that as a design constraint rather than adding a generic red banner. If several fields fail, a concise summary can help the user find them, while local messages explain individual corrections. For dynamic updates, choose an appropriate announcement mechanism and verify it in the implementation.

Our proposed message test is simple: after reading the error, can the person take a specific corrective action? Try a different value is often too vague. Explain the accepted format or constraint when doing so is appropriate and does not reveal sensitive account or system information.

Review the journey with a keyboard

Use a non-production copy and non-sensitive input. Start at the page entry point, move through controls with the keyboard and deliberately omit a required field. Observe where focus goes, whether the error is discoverable and whether returning to the field is straightforward.

Correct the value, submit again and inspect what happens to the remaining entries. Then simulate a server rejection and a connection failure separately. Do not merge those tests into one generic failure state: they answer different recovery questions.

Finally, complete a successful submission. The interface should distinguish completion from an in-progress request. For a timeout where the backend outcome is unknown, avoid confidently stating that nothing was saved. The review should document that uncertainty and the product's supported way to resolve it.

These are proposed acceptance exercises. This article does not claim that a particular component library or skill passes them.

Ask for evidence at each state

Have the agent return a compact state inventory with the reviewed control, triggering action, observed message, focus behavior and evidence collected. Keep automated checks, keyboard observations and assistive-technology checks separate.

A screenshot can show placement and contrast but cannot demonstrate every interaction. A markup inspection can establish a label relationship without proving the entire reading experience. If a required test could not be performed, record it as unverified instead of treating a generated implementation as evidence of success.

For a recurring form pattern, preserve the failure scenarios as review fixtures. That makes future design changes easier to evaluate: a slimmer layout should not remove the only persistent explanation of a field or obscure the recovery path.

Limitations and choosing a frontend skill

This walkthrough does not cover all requirements for accessibility, localization, security or sensitive transactions. Custom controls, complex multi-step flows and assistive-technology differences require additional evaluation. A generic checklist should not be advertised as a legal or standards-compliance guarantee.

The practical selection criterion for a frontend skill is whether it helps produce and verify the complete interaction, including unsuccessful attempts. Our earlier form-pattern introduction discusses broader reliability concerns. This article focuses on the user's recovery experience.

Browse the OpenAgentSkill directory for interface workflows, then ask a candidate to demonstrate its error states before accepting its default screenshot. A minimal form should remove unnecessary work, not the information needed to finish it.