Form Validation and Feedback
Form Validation and Feedback
| Topic | Technique | WCAG AA Requirement | 
|---|---|---|
| Labels and Instructions for Error Prevention | See the requirements and recommendations for Form Inputs, Labels, and Instructions, including: 
 | Required multiple | 
| Context-Sensitive Help: Context-sensitive help SHOULD be available. | Best Practice | |
| Critical Error Prevention | Web pages that process user input for any of the following: 
 MUST implement at least one of the following error prevention techniques: 
 | Required WCAG 3.3.4 | 
| Error Prevention (All Circumstances) | All web pages that process user input SHOULD implement at least one of the following error prevention techniques: 
 | Best Practice | 
| Error Detection on Submit | Error Identification: 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. Valid techniques include the following: 
 | Required WCAG 3.3.1 | 
| Dynamic Error Detection | Visible Real-Time Error Messages: Real-time error messages MAY be scripted to show on the screen for sighted users, but attempts to announce the real-time messages to screen reader users can be problematic (see the next two rows below). It is usually acceptable to wait to announce real-time errors until after form submission, assuming that no data has been saved yet. | Best Practice | 
| Live Announcements per Keystroke: ARIA live error messages SHOULD NOT be scripted to occur with every keystroke (to avoid overwhelming screen reader users), unless there is a delay built into the script to avoid announcements while the user is actively typing. | Best Practice | |
| Live Announcements on Leaving a Field (on blur): aria-live can be used to announce error messages on blur, but this technique should be used with caution, because the aria-live announcement may conflict with the screen reader's attempt to read the next element which receives focus, or with the user's keystrokes, causing the aria-live announcement to be interrupted or not announced at all. | A possible, but sometimes problematic way to meet WCAG 3.3.1 | |
| Error Message Characteristics | Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. | Required WCAG 3.3.3 | 
| Programmatically Associated: Error feedback SHOULD be programmatically associated with the appropriate element. | Best Practice | |
| Meaningful Error Message: Error feedback MUST clearly and accurately describe the error and/or how to fix the error. | Required WCAG 3.3.1 for error messages WCAG 3.3.3 for error suggestions | |
| Visible Error Message: Error feedback MUST be visible. | Required WCAG 3.3.1 | |
| Success Messages | Success Confirmation: The web page SHOULD confirm successful submission of data. Possible techniques include the following: 
 | Best Practice | 
