Forms Accessibility Audit: Where Every Site Leaks

What We Keep Finding

Here is the form experience our testers hit weekly. "Edit text." Which field is this? No label, so it is a guess. Fill everything, press submit, and silence. The errors painted red at the top were never announced, and which of the nine fields is wrong stays a secret. Start over, guess differently.

Now here is why your scanner said the form was fine, because this is the single most useful thing we can tell you. A field labeled by nothing but its placeholder still gets an accessible name, because the rules for working out a control's name fall through to the placeholder when nothing better exists. So the field passes the scanner's label check and passes W3C's own automated test for it. What it fails is a different rule, the one about labels and instructions, and that rule has no automated test in existence. Your tool is not broken. It was never looking.

The recovery question is the sharpest one on this page and it carries the strictest level. Losing eight fields to fix one is a Level A failure, because information a process already collected has to be filled in or offered back rather than demanded again. Note that the browser remembering it for you does not count. The site has to. And if the session times out mid-form and eats the lot, that is a separate rule with three exceptions, none of which is security, whatever your platform vendor says.

One more distinction that decides which finding gets written. A missing label and a present-but-unwired label are different failures against different rules with different fixes. Click the label text and watch whether focus moves. If it does not, the label exists and is not connected, which is the structure rule. If there was never a label at all, that is the labels-and-instructions rule. Reports that blur those two send your developer to the wrong file.