Accessibility Quick Check
Custom Form Validation
Native browser validation fires one alert at a time and breaks focus management. This review shows how custom JavaScript validation fixes the experience for keyboard users.
Read the full transcript ↓What Is It?
Native browser form validation shows one alert at a time on submit, with no styling, no focus management, and no way to see all errors at once.
Why It Matters
Keyboard users depend on consistent focus management and inline error messages to understand what went wrong and where to fix it. Native browser alerts fail on both counts.
How To Test
- Tab through the form without entering any values.
- Press Enter or click Submit.
- Observe whether all required field errors appear at once.
- Check whether focus moves to the first error field.
- Confirm error messages are inline and styled consistently.
The Fix
Adding noValidate to the form disables the native browser alert. Custom JavaScript validation then shows all required field errors simultaneously, inline, with focus moved to the first error field. Three ARIA attributes complete the fix:
aria-invalid— marks the field as failedaria-describedby— connects the field to its error messagerole="alert"— announces the error to screen readers immediately
This satisfies WCAG 3.3.1 and 3.3.3.
WCAG Reference
Related Skills
- Accessibility Testing
- Custom JavaScript Validation
- ARIA Attributes
- Keyboard Navigation
The clip opens with a title card reading: Accessibility Finding — Custom Form Validation — Keyboard Support. Presented by Shaun Vine.
The Problem. The contact form is shown with all three required fields empty — Your Name, Your Email, and Your Message. The user clicks the Send button. A native browser alert appears below the Name field reading "Please fill out this field." Only one field is flagged at a time. The voiceover states: "With native browser validation, submitting an empty required field triggers an alert — one field at a time."
The same form remains on screen. The voiceover continues: "There's no styling, no consistency, and no focus management." The browser alert has no styling that matches the interface, does not show all errors at once, and does not move keyboard focus to the affected field.
The Fix. The form now uses custom JavaScript validation. All three required fields display inline error messages simultaneously, each with a red border. The Name field has focus. Error messages read: "Please Enter Your Name.", "Please Enter Your Email Address.", and "Please Enter A Message." The voiceover states: "With custom validation, all required fields show errors at once — inline, styled to match the interface."
The user begins typing the letter M in the Name field. The Name field error clears immediately while the Email and Message errors remain. The voiceover states: "And as the user corrects each field, the error clears in real time."
The Code. The voiceover states: "Here's how it works in code."
A dark-themed code card is shown, titled "contact.js — form element". The form element is displayed with the noValidate attribute highlighted. The voiceover states: "Step 1: Disable the browser alert. noValidate disables the browser alert."
A second code card is shown, titled "contact.js — Name field". Three ARIA attributes are highlighted in the code:
aria-invalid— marks the field as failedaria-describedby— connects the field to its error messagerole="alert"— announces the error to screen readers immediately
The voiceover states: "Step 2: Make errors accessible. aria-invalid marks the field as failed. aria-describedby connects the field to its error message. And role=alert announces it immediately."
The clip closes with a card referencing the WCAG success criteria this fix addresses: