Form fields

What the rule requires

Every form field needs a name and role assistive technology can announce. An unlabeled field is a guessing game — “edit text, blank” tells the user nothing about what to type. And a form has to behave: it can’t jump somewhere when a field gets focus, it has to say what went wrong with an entry, and it has to let someone check what they submit.

• Name, role, value4.1.2 · A
• Labels or instructions3.3.2 · A
• Label in name2.5.3 · A
• Identify input purpose1.3.5 · AA
• On focus, on input3.2.1 / 3.2.2 · A
• Error identification and suggestion3.3.1 / 3.3.3 · A / AA
• Error prevention3.3.4 · AA

How Proof clears it

1. Fields registered automatically: widgets are tagged into Form structure with tooltips written.
2. Names checked, then confirmed by a person: Proof flags field names that don’t identify the field — “Text1”, two fields both called “Date”, a date format the name never states. Names are drafted from the printed label (by AI only where the page prints nothing), and a person accepts or edits them where they meet the field.
3. Focus order walked: fields are checked in the order a screen-reader user tabs through them.
4. Ghost widgets cleared: vestigial exporter-artifact widgets are removed — but only when provably junk.
5. Form behavior checked: what a field does when it gets focus or its value changes, how it reports a rejected entry, whether the form can submit, whether a field’s spoken name carries its printed label, and whether a field asking for personal details says what it collects. Each check passes when nothing in the form could break it — no validator, no submit action — and anything it finds goes to a person.

Watch it in Proof

What to expect