Accessible Form Label & Input Checker

1. What This Tool Actually Does

The checker parses the raw HTML of a page (fetched live or pasted directly) and extracts every <input>, <select>, and <textarea> element, excluding hidden, submit, button, image, and reset inputs which don't need a visible label. For each remaining control it checks, in order: does an <label for="id"> exist whose for attribute matches the control's id? Does the control carry aria-label or aria-labelledby? If both are absent but a placeholder is present, it's flagged as the placeholder-as-label anti-pattern rather than a total failure.

Every control is also checked for an autocomplete attribute, and the results are compiled into a 0–100 accessibility score: 25 points are deducted per fully unlabelled control, 12 points per placeholder-only control, giving you a quick, sortable severity signal before you open the detailed inventory below the scorecard.

2. How to Use It

1. Choose "Scan Form URL" for a live page (checkout, contact page, signup) or "Paste Form HTML" if the form is behind a login wall or rendered client-side.
2. Submit the form and review the Form Accessibility Score at the top — 90+ indicates fully labelled forms, below 70 flags meaningful accessibility debt.
3. Open the Form Input Inventory to see every detected control individually, each tagged Accessible or Unlabelled with its resolved label text shown where available.
4. For any red-flagged control, read the specific issue text — it distinguishes a placeholder-only anti-pattern from a completely unlabelled field, since the fixes differ.
5. Re-run the scan after each fix to confirm the score climbs and the flagged control moves into the Accessible column.

3. The Underlying WCAG Criteria

• 1.3.1 Info and Relationships — Level A: Form labels must be programmatically determinable, not just visually adjacent. A <label> sitting next to an input with no for/id pairing looks correct visually but conveys nothing to assistive technology.
• 3.3.2 Labels or Instructions — Level A: When content requires user input, labels or instructions must be provided so the user understands what data is expected.
• 4.1.2 Name, Role, Value — Level A: Every form control must expose an accessible name via the accessibility tree — the actual mechanism a screen reader queries, which an unlabelled or placeholder-only field fails to provide correctly.
• 1.3.5 Identify Input Purpose — Level AA: Inputs collecting common personal data (name, email, address, payment details) should declare a standard autocomplete token so browsers and assistive tools can autofill or announce the field's real-world purpose.

4. A Worked Example

Paste this snippet into the "Paste Form HTML" tab: <input type="email" placeholder="Email address" />. Because there is no id, no matching <label for>, and no aria-label, the parser marks hasExplicitLabel and hasAriaLabel as false. Since a placeholder attribute is present, it's classified as hasPlaceholderOnly: true rather than a hard failure, and the report surfaces the exact anti-pattern warning: "Uses placeholder text as the only label. Placeholders disappear when typing and are not persistent."

Now change it to: <label for="em">Email address</label><input type="email" id="em" placeholder="you@company.com" />. The regex-based label lookup finds the matching for="em" / id="em" pair, resolves the label text to "Email address", and the control moves into the Accessible column — the placeholder is now acceptable because it supplements, rather than replaces, a real label.

5. Who Actually Uses This Tool

• Agencies auditing e-commerce checkout flows: checkout forms are the single highest-conversion-risk area of a site, and unlabelled fields there are both an accessibility and revenue problem.
• WordPress developers using Contact Form 7, WPForms, or Gravity Forms: many drag-and-drop builders generate placeholder-driven markup by default; this tool catches it before the form ships.
• QA teams doing pre-launch regression checks: re-run the scan on staging URLs after every form redesign to catch labelling regressions before production deploy.
• Government and education portals: application, enrollment, and benefits forms are frequent Section 508 audit targets, and label association is one of the most commonly cited violations.

6. Common Mistakes & Limitations

• Client-side-rendered forms: the URL scanner reads server-delivered HTML only; forms injected after JavaScript hydration require the "Paste HTML" mode with markup copied from DevTools.
• Wrapping instead of pairing: a <label> that wraps an input (implicit labelling) without an explicit for/id pair may not be reliably detected by this regex-based parser — explicit pairing is the more robust and recommended pattern anyway.
• Visual-only labels: the tool cannot detect a label that's visually styled to look disconnected (e.g. positioned far from its input via CSS) even if the underlying markup is technically correct — always test with an actual screen reader too.
• Autocomplete token correctness: the checker only confirms an autocomplete attribute exists, not that its value is a valid WHATWG token (e.g. autocomplete="email" vs. a typo'd value) — cross-check against the HTML autofill spec for critical checkout fields.