Checking a sign-up form with a language model

A small sign-up form is a useful place to begin checking accessibility. It might have two fields, a submit button and a message when something goes wrong. Each part needs to work for people who use a keyboard, a screen reader or a magnified view.

A language model can help you inspect the form, explain unfamiliar terms and suggest changes. Treat its response as a set of findings to investigate. It cannot establish that a page is accessible simply by reading its source.

§ Start with a small piece of the page

Give the model the form’s HTML and any CSS or JavaScript that affects its behavior. Include a short description of what happens after submission. If you share only a screenshot, the model may notice visual problems, but it cannot reliably determine labels, reading order or keyboard behavior.

Remove personal information, credentials and real customer submissions first. A small example with invented values usually gives the model enough context.

Ask for a focused review instead of a general accessibility score. A useful first prompt is:

Review this sign-up form for possible accessibility problems. Focus on field labels, keyboard use, instructions and error messages. For each finding, identify the relevant element, explain who could be affected and suggest a minimal change. Separate issues visible in the code from questions that require browser testing. Do not claim that the form meets WCAG.

WCAG means Web Content Accessibility Guidelines, a widely used standard for web accessibility. You can ask the model to explain relevant criteria, but verify any criterion numbers or compliance claims against the standard.

§ Read the findings as questions to test

A useful review points to specific elements and explains their effect. For example, an email field may use placeholder text without a visible label. The placeholder disappears when someone types, removing an instruction they may still need. A properly associated label also gives assistive technology a reliable name for the field.

Other findings may depend on behavior the model cannot observe. A styled element might look like a button but fail to work from a keyboard. An error message might appear visually without being announced by a screen reader.

Ask the model to turn uncertain findings into checks you can perform:

• Can you reach each field and button with the Tab key, and move backward with Shift+Tab?
• Can you always see which element has keyboard focus?
• Can you submit the form using the keyboard?
• After an invalid submission, can you find the error, understand it and correct the affected field?
• When you zoom in, can you still read the instructions and use every control?

Run these checks in the actual page. Source code can suggest an intended experience; the browser reveals what the implementation does.

§ Make one change and check again

Choose one clear issue, such as a missing label, and request a small correction. Ask the model to explain the change in everyday language. Prefer standard HTML controls when they fit: they provide built-in behavior that custom controls would otherwise need to recreate.

After applying the change, repeat the relevant browser check. Use an automated accessibility checker to catch additional issues, and include a screen reader check where possible. Automated tools and model reviews cover only part of the experience; feedback from people with disabilities can reveal barriers they miss.

Be cautious when a model recommends adding ARIA attributes. ARIA supplies accessibility information to assistive technology, but incorrect attributes can make a control confusing. Ask whether ordinary HTML already provides the required meaning and behavior.

§ Keep a repeatable review note

Vana API can fit this workflow if you already use an OpenAI SDK. Its OpenAI-compatible endpoint lets you send a focused review request to a model such as Claude Sonnet 5.5. Requests are billed per real token, with no monthly fee. Create a Vana API account to try a review with a small form example.

Save the prompt, the findings you confirmed and the checks you performed. When the form changes, those notes give you a practical starting point for another review and help you distinguish a suggested fix from a verified improvement.