Form fields without labels and errors nobody hears: the three WCAG checks that fix most form failures

Three checks, three different failures

Most form accessibility faults fall into three groups that are tested separately. First, does every field that takes input have a label or instruction? That is 3.3.2 Labels or Instructions at Level A. Second, when the form detects an error, does it say in text which field is wrong and what is wrong? That is 3.3.1 Error Identification at Level A. Third, when something happens that is not a change of focus, such as "Message sent" or "3 results", is it announced to someone using a screen reader? That is 4.1.3 Status Messages at Level AA. A form can pass one and fail another, which is why a checklist names them individually.

• Placeholder text alone is a weak label: it disappears when typing starts.
• A red border alone is not an error message.
• A message that appears silently may never be heard.

Labels and instructions

W3C's guidance for 3.3.2 says every control that takes input needs a label or instruction, including each option in a group of radio buttons or checkboxes, and including optional fields. Instructions can explain an expected format, and long guidance can appear when the control has focus. The criterion is about providing them; the correct markup that ties a label to its control belongs to 1.3.1, and the accessible name belongs to 4.1.2. In practice use a real label element associated with each control and keep the label text visible.

• Click the label text: the field should receive focus.
• Mark required fields in text, not only by colour.
• Put format hints (for example a date format) where they are read with the field.

Errors in text that name the field

For 3.3.1, W3C says it is not sufficient to only re-display the form; the item in error must be identified and the problem described in text. "Email is not valid" meets 3.3.1; "Please provide a valid email address in the format name@domain.com" also helps people correct it, which is the separate 3.3.3 criterion. Colour and icons can reinforce the message but cannot be the only signal. If you turn off the browser's built-in messages with novalidate and show your own, make sure yours are in the page, tied to the field and kept after the error; native messages follow the browser language and cannot be styled, which is why teams replace them.

• Say which field, and say what is wrong.
• Keep what the person typed.
• Move or point focus to the first error, or give a summary near the top.

Status messages without moving focus

4.1.3 asks that status messages can be determined programmatically through role or properties so that assistive technology can announce them without the user's focus moving. W3C's techniques use role=status for results and state, and role=alert or live regions for errors and warnings, and it lists overuse of assertive announcements for unimportant content as a failure. MDN's example adds aria-live="polite" to the element that holds a custom validation message, and the Next.js documentation does the same for a message returned by a form action.

• Test with a screen reader: submit the form and listen for the result.
• Do not announce every keystroke.
• A success message after submit is a status message, not a page change.

How the paid jobs use these checks

Our accessibility job (posted test price from £595, untested, quoted after we see the flow) includes these three criteria in its default checklist and accepts them by hand: each control announced with its label, each error announced in text with the field named and a status message after submit announced without moving focus, with one agreed screen reader and browser. It does not give a legal statement. If the form is also being flooded with junk or rejecting real names, those are covered by our separate form job (posted test price £245, untested). Send the form and what you see when it fails in your first enquiry, not customer data.