Form Labels Accessibility Checker
Missing form labels are the third most common WCAG violation, found on 47% of home pages. WCAG 1.3.1 and 3.3.2 require that every input has a programmatically associated label.
No signup required. Results in under 60 seconds.
What WCAG 1.3.1 and 3.3.2 Require for Forms
WCAG 1.3.1 (Info and Relationships, Level A) requires that information, structure, and relationships conveyed through presentation are programmatically determinable. For forms, this means every input must be associated with its label in the code, not just visually. WCAG 3.3.2 (Labels or Instructions, Level A) requires that labels or instructions are provided when user input is required. Together, these criteria ensure that screen reader users know what information each field expects. The WebAIM Million study finds missing form labels on 47% of home pages, making it the third most prevalent violation. Forms are where accessibility failures have the most direct impact — users literally cannot complete tasks like signing up, checking out, or submitting inquiries when labels are missing.
Proper Label Association Methods
There are several valid ways to associate labels with form controls:
- Explicit label with for/id:
<label for="email">Email address</label><input id="email" type="email">— the most reliable method, works across all assistive technologies - Wrapping label:
<label>Email address <input type="email"></label>— implicit association by nesting the input inside the label element - aria-label:
<input type="search" aria-label="Search products">— use when a visible label is not part of the design (search fields, icon-only inputs) - aria-labelledby:
<input aria-labelledby="billing-header email-label">— combines multiple text elements into one accessible name, useful for complex form layouts
Methods that do NOT meet WCAG requirements alone:
placeholder— disappears on input, fails 1.3.1 because it is not a persistent labeltitle— a tooltip, not announced consistently by screen readers- Visually adjacent text without programmatic association — looks labeled but is not
Advanced Form Accessibility Patterns
Complex forms require additional accessibility techniques:
- Grouped fields (radio/checkbox):
<fieldset><legend>Payment Method</legend><label><input type="radio" name="pay"> Credit Card</label><label><input type="radio" name="pay"> PayPal</label></fieldset> - Required fields:
<label for="name">Full Name <span aria-hidden="true">*</span></label><input id="name" required aria-required="true"> - Error messages:
<input id="email" aria-describedby="email-error" aria-invalid="true"><span id="email-error">Please enter a valid email</span> - Help text:
<input id="pwd" aria-describedby="pwd-help"><span id="pwd-help">Must be 8+ characters with a number</span> - Autocomplete:
<input type="email" autocomplete="email">— WCAG 1.3.5 (Level AA) requires autocomplete attributes for fields collecting personal data
How CompliScan Detects Form Label Issues
CompliScan identifies form accessibility violations including: <input> elements without any associated label (no <label>, no aria-label, no aria-labelledby), inputs that rely solely on placeholder for labeling, <select> and <textarea> without labels, radio and checkbox groups without <fieldset>/<legend>, and form controls with duplicate or conflicting labels. Each violation includes the specific element, its current labeling state, and an AI-generated fix with the exact HTML needed. For the ADA Title II deadline of April 24, 2026 and the European Accessibility Act, proper form labeling is mandatory. CompliScan catches the structural violations that automated tools can reliably detect — approximately 30-40% of form accessibility issues. Manual testing should verify that labels are meaningful, error messages are helpful, and the form flow is logical. Run a free scan or use Shield ($49/mo) for weekly monitoring of form accessibility across your site.
Frequently Asked Questions
Can I use placeholder instead of a label?
No. Placeholder text disappears when the user begins typing, which means they cannot verify what the field is for after entering data. Placeholders also typically have insufficient contrast (light gray text). WCAG requires a persistent, programmatically associated label. You can use placeholders as supplementary hints in addition to labels, but never as the sole label. This is one of the most common form accessibility mistakes.
Do hidden labels count as accessible labels?
Yes, visually hidden labels (using CSS like .sr-only or .visually-hidden) are valid for WCAG compliance because screen readers can still access them. This technique is useful for inputs where a visible label would clutter the design — like search boxes or icon-only actions. However, visible labels are always preferred when possible because they benefit all users, including those with cognitive disabilities.
How do I label a search input without a visible label?
Use aria-label: <input type='search' aria-label='Search products'>. Alternatively, use a visually hidden label: <label for='search' class='sr-only'>Search products</label><input id='search' type='search'>. Both methods provide an accessible name for screen readers while keeping the visual design clean. The magnifying glass icon alone is not sufficient as a label.
What is the difference between aria-label and aria-describedby?
aria-label provides the primary accessible name (what the element is). aria-describedby provides supplementary description (additional context). Screen readers announce the name first, then the description. For a password field: the label says 'Password' (what it is) and aria-describedby links to help text saying 'Must be 8+ characters' (additional context). Both are important but serve different roles.
More Free Tools
Check Your Website Now
Enter your URL below and get a free accessibility report with AI-powered fix suggestions in under 60 seconds.
No signup required. Results in under 60 seconds.