How do you get a coding assistant to write accessible HTML forms?

What makes an HTML form accessible?

An accessible form is one that people can fill in and correct whatever they use: a mouse, a keyboard, a screen reader or speech input. The Web Content Accessibility Guidelines (WCAG 2.2) set the baseline in three success criteria that matter most here:

• 3.3.2 Labels or Instructions: "Labels or instructions are provided when content requires user input." (Understanding 3.3.2)
• 3.3.1 Error Identification: "If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text." (Understanding 3.3.1)
• 1.3.5 Identify Input Purpose: fields that collect information about the user must have a purpose that "can be programmatically determined", which in HTML means the autocomplete attribute. (Understanding 1.3.5)

The W3C's forms tutorial gives the core technique: "use the label element to associate text with form elements explicitly. The for attribute of the label must exactly match the id of the form control."

Which prompt lines fix the usual mistakes?

A vague "make it accessible" leaves the assistant to guess. Name the element or attribute for each job. CodeLifter has not run these lines against a named assistant; they ask for what the W3C and MDN pages describe, and you still check the output.

Common mistake	Prompt line	What to look for in the answer
Placeholder used as the only label	"Give every field a visible label element; use placeholder only for an example value, never as the label"	A <label> before each <input>
Label not tied to its field	"Each label's for attribute must exactly match its input's id"	Identical for and id strings
Radio buttons with no group name	"Wrap each radio or checkbox group in fieldset with a legend that asks the question"	<fieldset> and <legend>
Required shown only by an asterisk or colour	"Mark required fields with the required attribute and the word (required) in the label text"	required plus visible text
Errors shown only in red or in an alert box	"Show each error as text next to its field, link it with aria-describedby, and set aria-invalid=true on the field"	An element with an id that the field's aria-describedby names
No autofill hints	"Add autocomplete tokens such as name, email and tel to fields about the user"	autocomplete="email" and similar
A div or span used as the submit button	"Use a button element with type=submit"	A real <button>

MDN's placeholder reference explains the first row: placeholders "should only be used to show an example of the type of data that should be entered into a form; never as a replacement for a <label> element". The keyboard thread explains why the last row matters for focus and key handling.

A prompt you can paste

Write an HTML contact form with fields for name, email, phone (optional)
and message, plus a preferred-contact choice of email or phone.
- Every field has a visible <label> whose for matches the input's id.
- Placeholder is only an example value, never the label.
- Group the contact choice radios in <fieldset> with a <legend>.
- Required fields use the required attribute and say (required) in the label.
- Add autocomplete="name", "email" and "tel" to those fields.
- On submit, validate in plain JavaScript. For each error, write text
  into an element next to the field, link it with aria-describedby,
  set aria-invalid="true", and move focus to the first field in error.
- Use <button type="submit">. No divs as buttons, no innerHTML.

The focus step comes from the W3C notifications tutorial, which says that when submitted data has errors "it is convenient to set the focus to the first element that contains an error". The innerHTML ban is explained in the innerHTML thread. For how each line of a prompt is chosen, see How to write a coding prompt.

Should the rules go in a rules file instead?

Put them in both places. The prompt keeps the rules next to the task; a rules file such as AGENTS.md keeps them in every session, so a form added three weeks later gets the same treatment. A short section works:

## Forms
- Visible <label for> on every field; placeholder is never the label.
- fieldset and legend for radio and checkbox groups.
- required attribute plus "(required)" in the label text.
- Errors: text next to the field, aria-describedby, aria-invalid="true".
- autocomplete tokens on fields about the user.

The AGENTS.md thread covers which file each tool reads.

How do you test the form you got?

1. Press Tab from the top of the page. Every field and the submit button should take focus, in reading order.
2. Click each label. The field it names should take focus; if it does not, for and id do not match.
3. Submit the form empty. Each error should appear as text next to its field, and focus should land on the first one.
4. Open your browser's accessibility inspector on a field in error and confirm its accessible name is the label and its description is the error text.
5. Turn on a screen reader (VoiceOver on macOS, NVDA on Windows) and fill in the form without looking. The W3C notes that screen readers often switch to a "Forms Mode" where they "usually only read aloud form elements", so instructions sitting outside a label or aria-describedby target can be missed.
6. Check autofill: your browser should offer your saved name and email.

Short version

• Name the elements: label with matching for/id, fieldset/legend, required, autocomplete, button.
• Never let a placeholder stand in for a label.
• Tie each error to its field with aria-describedby and aria-invalid, and move focus to the first error.
• Repeat the rules in AGENTS.md so every session gets them.
• Test with Tab, a label click, an empty submit and a screen reader.