Form Accessibility Checker – Test Form Labels & ARIA

Labels are essential for form accessibility because: Screen readers: Read label text to identify form fields Clickable area: Clicking label focuses the associated input Context: Provides clear purpose for each field Voice control: Users can say the label text to interact WCAG requirement: Required by 3.3.2 (Labels or Instructions) Without labels: Screen reader users hear only "edit text" or "checkbox" without knowing the purpose.

No! Placeholders are NOT a substitute for labels. Here's why: Disappears: Placeholder vanishes when user types, losing context Low contrast: Usually gray text that's hard to read Memory: Users can't review what the field is for while typing Screen readers: May not announce placeholders consistently Cognitive load: Forces users to remember field purpose Correct approach: <label for="email">Email Address</label> <input id="email" type="email" placeholder="you@example.com" aria-describedby="email-help" > <span id="email-help">We'll never share your email</span> Use placeholder for examples or hints, always with a proper label.

There are several ways to label form inputs accessibly: Method 1: for/id association (Preferred) <label for="username">Username</label> <input id="username" type="text"> Method 2: Wrapping label <label> Username <input type="text"> </label> Method 3: aria-label <input type="text" aria-label="Username"> Method 4: aria-labelledby <h3 id="username-heading">Username</h3> <input type="text" aria-labelledby="username-heading"> Best practice: Use Method 1 (for/id) when possible - it provides the best compatibility and user experience.

Autocomplete attributes help users fill forms faster and improve accessibility. Common values: name: Full name given-name: First name family-name: Last name email: Email address tel: Phone number street-address: Street address address-level2: City address-level1: State/Province postal-code: ZIP/Postal code country: Country cc-number: Credit card number cc-exp: Credit card expiration username: Username new-password: New password field current-password: Login password See the HTML Specification for the complete list.

Accessible error messages require several techniques: Use aria-invalid: Set to "true" when field has error <input aria-invalid="true"> Use aria-describedby: Associate error message with field <input id="email" aria-describedby="email-error"> <span id="email-error">Email is required</span> Visual indicators: Use color AND icons/text (not color alone) Live regions: Announce errors with aria-live for dynamic validation Focus management: Move focus to first error on submit Clear messages: Be specific about what's wrong and how to fix Complete example: <label for="email">Email *</label> <input id="email" type="email" required aria-invalid="true" aria-describedby="email-error" > <span id="email-error" role="alert"> Please enter a valid email address </span>

Use <fieldset> and <legend> to group related form controls: Example for radio buttons: <fieldset> <legend>Shipping Method</legend> <label> <input type="radio" name="shipping" value="standard"> Standard (5-7 days) </label> <label> <input type="radio" name="shipping" value="express"> Express (2-3 days) </label> </fieldset> Example for address fields: <fieldset> <legend>Billing Address</legend> <!-- Address fields here --> </fieldset> Benefits: Screen readers announce the legend with each field Provides context for grouped fields Required for radio button groups (WCAG 1.3.1) Improves form comprehension