Accessible Form Checker
Fast, secure, client-side utility running entirely in your browser with zero server dependencies.
Accessible Form Checker
Verify web forms for accessible label associations, automated input suggestions, keyboard operability, and screen reader error announcements.
Accessible Form Checker - WCAG 2.2 Form Input, Label & Error Linter: Free Accessible Form Checker tool: audit form accessibility under WCAG 1.3.1 and 3.3.2, checking label associations, fieldset/legend groupings, and error.
How to Use the Accessible Form Checker
Paste HTML Form Code
Insert any web form containing inputs, dropdowns, textareas, checkboxes, or radio button groupings.
Verify Label Associations
The tool checks for explicit
Check Autocomplete Attributes (SC 1.3.5)
Validates that fields collecting personal information (name, email, address, phone) provide browser autofill tokens.
Review Fieldset Grouping & Error Linkages
Confirms that radio/checkbox options are enclosed in
Comprehensive Guide: Accessible Form Checker
Web forms represent the primary vehicle for high-stakes digital transactions—including creating user accounts, filing government applications, purchasing e-commerce merchandise, and entering credit card credentials. Because form completion requires precise coordination between visual perception, motor control, and cognitive comprehension, forms represent one of the most heavily litigated areas in digital accessibility.
A foundational requirement under WCAG 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value) is programmatic label association. When a user focuses an input, the screen reader must announce the field’s label immediately. Placing a visual text label next to an input without connecting them via `
WCAG 2.1 introduced Success Criterion 1.3.5 (Identify Input Purpose). Under this Level AA rule, any form input that collects information about the user (such as email, name, postal code, or telephone number) must include an `autocomplete` attribute (e.g. `autocomplete="email"`). Autocomplete enables browsers and assistive tools to populate form fields automatically, dramatically reducing cognitive burden for users with memory impairments and eliminating tedious typing for individuals with motor disabilities.
Accessible error handling requires programmatic linkage. When a user submits an invalid form, displaying a red visual border or text paragraph is insufficient. Under WCAG 3.3.1 (Error Identification) and 3.3.3 (Error Suggestion), the invalid input must feature `aria-invalid="true"`, and the error message container must be programmatically connected using `aria-describedby="error-id"`. This ensures the screen reader announces the exact error message the moment the user focuses the field.
Key Features & Capabilities
Label Association Verification
Audits explicit for/id pairs, wrapping labels, and aria-labelledby programmatic relationships.
SC 1.3.5 Autocomplete Compliance
Checks for standard browser autofill tokens across email, address, phone, and name inputs.
Fieldset & Legend Auditing
Ensures radio button clusters and multi-checkbox lists have parent legends establishing the question context.
Error Message Linkage Check
Validates aria-invalid="true" and aria-describedby associations for immediate auditory error announcements.
Eliminates Placeholder Anti-Patterns
Flags forms relying on disappearing placeholder text instead of persistent visible labels.
Production-Ready Remediation Code
Outputs corrected HTML snippets with explicit label IDs and aria-describedby error blocks.
Frequently Asked Questions
While wrapping an input inside a is valid HTML, some legacy screen readers and voice-control software (like Dragon NaturallySpeaking) operate more reliably when an explicit for/id pairing ( and <input id="email-id">) is used. Using explicit for/id is considered universal enterprise best practice.
The native HTML5 required attribute enforces both browser client-side form validation (preventing submission if empty) AND informs assistive technologies. aria-required="true" only informs assistive technologies without triggering native browser error popups.
Individual radio buttons have individual labels (e.g. "Credit Card", "PayPal", "Bank Wire"). Without a parent and Payment Method, a screen reader user moving between radio options hears "Credit Card, radio button", but has no programmatic way to know what overarching question they are answering.
Pair the input with aria-invalid="true" and aria-describedby="err-id", and give the error message container role="alert" or aria-live="assertive". This causes screen readers to interrupt and immediately vocalize the error without requiring the user to navigate to the bottom of the page.
If a visible label cannot fit into your visual design (such as a compact search bar in a header), do not omit the label. Instead, include the label in HTML and apply the .sr-only class (Search) so assistive technology can announce it while keeping it visually hidden.