Error Identification Accessibility Checker
WCAG 3.3.1 requires that form errors are identified and described in text. WCAG 3.3.3 requires correction suggestions. Inaccessible error handling blocks users from completing critical tasks.
No signup required. Results in under 60 seconds.
What WCAG 3.3.1 and 3.3.3 Require
WCAG 3.3.1 (Error Identification, Level A) requires that if an input error is automatically detected, the item in error is identified and the error is described to the user in text. WCAG 3.3.3 (Error Suggestion, Level AA) requires that if an input error is detected and suggestions for correction are known, the suggestions are provided to the user — unless doing so would jeopardize security or the purpose of the content. These criteria address a critical usability barrier: users cannot fix errors they cannot perceive or understand. Red borders and color-only indicators fail users with color blindness. Error messages that only appear visually without programmatic association are invisible to screen reader users. Forms that clear all inputs on validation failure punish users with motor disabilities who laboriously entered data.
Accessible Error Handling Patterns
Implementing error handling that meets WCAG 3.3.1 and 3.3.3:
- Inline errors with association:
<input id="email" aria-invalid="true" aria-describedby="email-err"><span id="email-err" role="alert">Please enter a valid email address, e.g. name@example.com</span> - Error summary at form top:
<div role="alert"><h2>2 errors found</h2><ul><li><a href="#email">Email: Enter a valid email address</a></li></ul></div>— links jump focus to the problematic field - Live region for async validation:
<div aria-live="polite" id="username-status"></div>— updated via JavaScript:document.getElementById('username-status').textContent = 'Username already taken' - Do not rely on color alone: Red borders must be accompanied by text descriptions and icons. Use
aria-invalid="true"to programmatically indicate the error state
Common Error Handling Violations
Frequent accessibility failures in error handling:
- Color-only error indicators: A red border on the invalid field with no text explanation. Users with color blindness or screen readers cannot detect this
- No programmatic association: An error message appears below the field but is not linked via
aria-describedby. Screen readers do not announce it when the field receives focus - Generic error messages: "Invalid input" does not help the user fix the error. WCAG 3.3.3 requires specific suggestions: "Enter a date in MM/DD/YYYY format"
- Page refresh clears data: Server-side validation that reloads the page and clears completed fields forces users to re-enter everything — especially painful for motor disability users
- Missing aria-invalid: The
aria-invalid="true"attribute tells screen readers the field has an error. Without it, users must navigate to the error text separately to discover the problem
How CompliScan Detects Error Handling Issues
CompliScan checks for structural indicators of inaccessible error handling: form inputs with aria-invalid="true" but no associated error text (via aria-describedby), required fields without the required or aria-required attribute, and form elements lacking proper label associations that would make error identification meaningful. The scanner also detects forms without any visible or programmatic error handling mechanism. While detecting the quality of error messages requires manual review, CompliScan identifies the structural foundations that make accessible error handling possible. Automated tools catch approximately 30-40% of form error accessibility issues — supplement with manual form submission testing to verify error messages are clear, specific, and properly announced. CompliScan's Shield plan ($49/mo) monitors your forms for accessibility regressions as you update your site.
Frequently Asked Questions
Can I use only color to indicate form errors?
No. WCAG 1.4.1 (Use of Color) requires that color is not the sole visual means of conveying information. Error indication must include text descriptions and ideally icons in addition to any color change. A red border alone fails — add text like 'This field is required' alongside the visual indicator. Approximately 8% of men have color vision deficiency and may not perceive red borders.
Should errors be shown inline or in a summary?
Both approaches are valid, and the best practice is to use both. An error summary at the top of the form with links to each problematic field gives users an overview. Inline errors next to each field provide context when the user reaches that field. The summary should appear on submission, move focus to itself (using role='alert' or by focusing the summary heading), and each link should jump to the relevant field.
How do I handle real-time validation accessibly?
Use aria-live='polite' regions that update as the user types. Do not announce errors on every keystroke — wait until the user pauses or leaves the field (onblur). Use aria-invalid='true' when the field is in an error state and remove it when corrected. Avoid announcing 'valid' states — only announce errors and corrections. Provide debouncing (300-500ms delay) to avoid overwhelming screen reader users with rapid announcements.
What makes a good error message?
A good error message identifies the field, describes the error, and suggests how to fix it. Bad: 'Invalid input'. Good: 'Email address must include an @ symbol, e.g. name@example.com'. For date fields: 'Enter the date in MM/DD/YYYY format'. For password fields: 'Password must be at least 8 characters and include one number'. Specific, actionable messages reduce user frustration for everyone, not just users with disabilities.
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.