Accessibility notes from a signup form review

A signup form is a useful place to start an accessibility review: one page, a clear task, and several states to inspect. This walkthrough uses a language model to organize evidence and propose small fixes, then returns to the browser for verification. Keep the distinction explicit: automated evaluation supports a review, but some accessibility checks require human judgment. ([w3.org](https://www.w3.org/WAI/test-evaluate/tools/selecting/))

§ Step 1: Define the task and its boundaries

Choose one journey: enter an email address and password, submit the form, correct an error, and reach confirmation. Record the page version, browser, viewport, and expected behavior. Include the initial, invalid, loading, and successful states in your review scope.

Write a short instruction before collecting evidence: Review this signup journey for accessibility barriers. Separate findings supported by supplied evidence from questions that require browser testing. Do not declare the page compliant. Treat the output as a working issue list, not an accessibility certificate.

§ Step 2: Collect a small evidence packet

Gather the rendered HTML for the form, relevant styles, validation behavior, and any existing automated accessibility report. Include screenshots if your chosen model accepts images, but do not make them the only evidence. W3C's preliminary checks cover distinct concerns such as labels, contrast, keyboard access, and visible focus; collect evidence appropriate to each. ([w3.org](https://www.w3.org/WAI/test-evaluate/preliminary/?utm_source=openai))

Use synthetic entries instead of customer information. Remove credentials, session tokens, and unrelated page content before sending anything. Label every artifact with its state, such as initial form or invalid password, so the reviewer does not confuse different moments in the journey.

§ Step 3: Send a bounded review request

If your review workflow already uses an OpenAI-compatible client, Vana API provides a compatible connection for models such as Gemini 3.1 Pro. Keep the evidence packet and instructions together in one request. To follow along, create a Vana API account and configure your client using its connection instructions. ([vanaapi.com](https://vanaapi.com/))

Ask for a consistent response structure:

• Location: the element, selector, or supplied line reference.
• Evidence: the exact observation supporting the concern.
• User impact: the task that may become difficult or impossible.
• Proposed change: the smallest relevant correction.
• Verification: a browser test, plus anything still unknown.

Add a constraint: Do not invent missing markup, computed styles, accessible names, or runtime behavior. Request additional evidence when necessary. Ask for a short, prioritized list rather than an exhaustive rewrite.

§ Step 4: Check one finding against the source

Suppose the response identifies an email field with placeholder text but no associated label. Inspect the rendered element before accepting the finding. Look for an explicit label association or another naming mechanism. W3C recommends explicitly associated labels where possible; the label's for attribute must match the control's id. ([w3.org](https://www.w3.org/WAI/tutorials/forms/labels/))

If the concern is confirmed, request a minimal patch that preserves the component's existing structure. Review the patch yourself. Keep the change focused on the verified problem rather than accepting unrelated styling, validation, or state-management changes.

§ Step 5: Test the behavior yourself

Follow the journey without a mouse. Check whether you can reach and operate each control, identify the current focus position, submit invalid data, and recover. Keyboard testing is essential because functionality generally needs to be available through a keyboard interface, with limited exceptions. A source-code review alone does not demonstrate that behavior. ([w3.org](https://www.w3.org/WAI/WCAG22/Understanding/keyboard?utm_source=openai))

Then examine the form with a screen reader and inspect its accessibility tree. Record what actually happens, including the browser and assistive technology used. Feed observations back into the review as evidence, not as a request for the model to guess what a user would hear.

§ Step 6: Close issues with repeatable checks

After applying each patch, repeat the same journey and rerun your automated checks. Save the original evidence, accepted change, and observed result together. Mark unresolved questions explicitly rather than converting them into passes.

Finish with a compact review note: scope tested, barriers confirmed, fixes verified, and remaining work. The useful output is not a reassuring score. It is a small set of traceable improvements and a testing routine you can repeat when the form changes.