🖋️
Web Accessibility Resources
  • Web Accessibility
  • Cheat Sheets
    • Structure and Semantics
      • Page Title
      • Language
      • Headings
      • Landmarks
      • Lists
      • Tables
      • Iframes
      • Markup Validity
      • Other Semantic Elements
    • Links & Navigation
      • Links
      • Site Navigation
      • Within-Page Navigation
      • Reading Order/Focus Order
    • Images & Visual Design
      • Images
      • Color & Contrast
      • Text Styles, Resize, Reflow, and Zoom
      • Visual Cues
      • Adaptive and Responsive Output
    • Multimedia, Animations, and Motion
      • Audio and Video
      • Animation, Motion, and Timed Content
    • User Input, Forms, and Dynamic Content
      • Device-Independent User Input
      • Form Input, Labels, and Instructions
      • Form Validation and Feedback
      • Dynamic Content (JavaScript, AJAX)
      • Custom Widgets (JavaScript, ARIA)
      • CAPTCHA
    • Keyboard Commands
  • Semantic Group Labels
Powered by GitBook
On this page

Was this helpful?

  1. Cheat Sheets
  2. User Input, Forms, and Dynamic Content

Form Validation and Feedback

PreviousForm Input, Labels, and InstructionsNextDynamic Content (JavaScript, AJAX)

Last updated 5 years ago

Was this helpful?

Topic

Technique

WCAG AA Requirement

Labels and Instructions for Error Prevention

See the requirements and recommendations for , including:

  • Labels for inputs

  • Labels for groups of inputs

  • Instructions about inputs

  • Instructions about an entire form, a group, or a section

  • Required fields (in the full list of recommendations)

  • Data input restrictions (in the full list of recommendations)

  • Disabled fields

  • Time limits

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:

  • legal commitments,

  • financial transactions,

  • user-controllable data (e.g. user profile, social media posts, OR

  • test/quiz responses

MUST implement at least one of the following error prevention techniques:

  • Reversible: Submissions are reversible.

  • Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

  • Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Required

Error Prevention (All Circumstances)

All web pages that process user input SHOULD implement at least one of the following error prevention techniques:

  • Reversible: Submissions are reversible.

  • Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.

  • Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

best practice

Error Detection on Submit

Error Identification: If an error is automatically detected, the input with the error MUST be identified. Valid techniques include the following:

  • Add aria-invalid="true" to the input

  • Identify the input (referencing the label):

    • in a simple JavaScript alert

    • with information associated with the input via aria-describedby (widely supported) or aria-errormessage (not yet widely supported)

    • with error text added to the input's label (other techniques are more semantically correct, but this is a reliable method)

    • with text on the web page (it may be appropriate to move the keyboard focus to the error message)

    • with an aria-live or role="alert" announcement

    • with information about the error in the page <title> if the submission causes a page reload or a new page load.

Required

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: ARIA live error messages SHOULD NOT be scripted to occur when a user leaves a field, because the aria-live announcement will may conflict with the screen reader's attempt to read the next element which receives focus, causing some information to be interrupted or not announced at all.

best practice

Error Message Characteristics

Error Suggestion: 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.

Required

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.

best practice

Visible Error Message: Error feedback MUST be visible.

Required

Success Messages

Success Confirmation: The web page SHOULD confirm successful submission of data. Possible techniques include the following:

  • a simple JavaScript alert

  • with confirmation text on the web page (it may be appropriate to move the keyboard focus to the error message)

  • with an aria-live or role="alert" announcement

  • with the confirmation message in the page <title> if the submission causes a page reload or a new page load.

best practice

Form Input, Labels, and Instructions
WCAG 3.3.4
WCAG 3.3.1
WCAG 3.3.3
WCAG 3.3.3