Loading...
Loading content...
Loading content...
Clearly identify form errors and describe them in text that screen readers can access.
Why it matters: Users need to know what went wrong and where to fix it.
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
What This Means: This success criterion requires that when form validation automatically detects an input error, the system must identify which field has the error and describe the error in text format. Error identification cannot rely solely on visual indicators like color changes or icons.
Why It's Important: Users need to know what went wrong and where to fix it. Visual-only error indicators (like red borders) are not accessible to screen reader users or users who cannot perceive color differences. Text-based error messages ensure that all users can understand what errors occurred and how to fix them.
Provide clear, specific error messages in text format. Use aria-invalid='true' to mark fields with errors. Use aria-describedby to associate error messages with their fields. Place error messages near their associated fields. Use role='alert' or aria-live='polite' so screen readers announce errors. Ensure error messages are in the DOM and accessible to assistive technologies. Make error messages specific and actionable (e.g., 'Email field: Please enter a valid email address' instead of just 'Error').
This criterion ensures that all users can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that screen reader users can access and understand the content, improving their overall experience and ability to use the website effectively.
This criterion ensures that users with cognitive disabilities can access and understand the content, improving their overall experience and ability to use the website effectively.
Impact: When this criterion is properly implemented, it removes barriers for these user groups and creates a more inclusive web experience for everyone.
A form field turns red when there's an error, but no text message explains what's wrong.
<input type="email" style="border: 2px solid red;">An error is indicated by both visual styling and a clear text message.
<input type="email" aria-invalid="true" aria-describedby="email-error"><span id="email-error">Please enter a valid email address</span>This success criterion benefits the following user groups:
Tip: Use this checklist during development and testing to ensure all requirements for 3.3.1 Error Identification are met. Check off items as you complete them.
To meet this success criterion, ensure the following requirements are met:
While meeting the minimum requirements ensures compliance, consider these enhancements for a better user experience:
If the field turns red, that's enough to identify the error.
Visual indicators alone are not sufficient. Error messages must be in text format so screen readers can announce them. Color-blind users may also miss color-only indicators.
I can show errors in a popup or alert box.
While alerts can work, inline error messages associated with fields are more accessible. Errors should be programmatically associated with their fields using aria-describedby.
Error messages only need to appear after form submission.
Errors can be shown in real-time as users interact with fields, which is often more helpful. However, they must still meet the identification requirements.
Errors indicated only by color change (red border) without text.
Add text error messages. Use aria-invalid='true' and aria-describedby to associate errors with fields. Include visible error text, not just visual styling.
Generic error messages that don't identify the specific field or issue.
Provide specific error messages that identify the field and describe the problem. Example: 'Email field: Please enter a valid email address' instead of just 'Error'.
Error messages not associated with their fields programmatically.
Use aria-describedby to link error messages to their fields. Ensure error messages are in the DOM and accessible to assistive technologies.
Error messages that aren't announced to screen readers.
Use role='alert' or aria-live='polite' for error messages so screen readers announce them. Ensure errors are in the DOM when they occur.
Error messages placed far from the fields they describe.
Place error messages near their associated fields. Use aria-describedby to programmatically associate them even if visually separated.
Note: These are official W3C resources for 3.3.1. For the most up-to-date information and detailed technical guidance, always refer to the official W3C documentation.
Implementing 3.3.1 Error Identification correctly requires understanding your specific context. Code solutions vary significantly based on multiple factors:
HTML, React, Vue, Angular, PHP, Python, and other frameworks each have different patterns and best practices.
Server-side rendering, client-side rendering, static generation, and hybrid approaches require different solutions.
Your existing components, styling approach, and UI library influence how accessibility must be implemented.
Your specific user base, content type, and interaction patterns determine the most appropriate implementation.
We provide tailored implementation guidance by analyzing your specific technology stack, coding patterns, design system, and project requirements. Our team reviews your codebase and provides custom solutions that integrate seamlessly with your existing architecture.
Get Custom Implementation HelpPart of
Understandable PrincipleGuideline
3.3 Input Assistance