• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
Digital A11Y

Digital A11Y

  • About
  • Articles
  • WAI-ARIA
  • WCAG
  • Resources
    • Cheat Sheets
    • A11Y Blogs
    • A11Y Toolkit
  • Contact
Home » Understanding SC 3.3.3 Error Suggestion

Understanding SC 3.3.3 Error Suggestion

Last Modified: November 21, 2019 by Raghavendra Satish Peri Leave a Comment

3.3.3 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. (Level AA)

While SC 3.3.1 Error Identification talks about providing the errors in text format the SC 3.3.3 Error Suggestion is a little different & easy to follow. The intention of this success criterion is to help users identify the errors & provide them with right hints if the form validation fails. For example if an email address is left blank or entered incorrectly, the error message “invalid email address” is not sufficient. In this instance, the error message is not providing enough information to the user to fix the error & provide the right data to pass through the form validation. The right error would be “invalid email address, enter [email protected]”. In this example, users are aware of what pattern to enter in specific form fields that need a specific data pattern. The error suggestion also applies to the fields that are required to pass the form validation. Here letting the users know the specific field is required along with right hint of how to enter that data will enable them to complete the form submission.

Users who benefit this checkpoint are:

  • Visually impaired: screen reader users or low vision users rely on hints & errors to get through long form submissions
  • Cognitive users: if right set of errors are provided it reduces the cognitive load on the users
  • Motor Disable users: when an error is identified & focus is moved to that form control & if the error is properly explained it reduces the number of keystrokes that a motor disable user has to go through.

Points to Ponder

  • Provide descriptive errors
  • Provide visible hints that will enable the users to avoid errors during form submissions
  • Associate the errors with form controls using aria-describedby
  • Move the focus to the form control that has the error once validation failed, this reduces the number of key strokes
  • Mark the required fields with asterisk visually & programmatically with aria-required.

References

Understanding Success Criterion 3.3.3

Share A11Y Love

  • Twitter
  • LinkedIn
  • Facebook
  • Reddit

More Accessibility Articles

Filed Under: WCAG

About Raghavendra Satish Peri

Raghava is a digital accessibility evangelist working at Deque Systems as Senior Accessibility Consultant breaking web accessibility & mobile accessibility challenges.

He authors an Accessibility Blog & is galvanising the adoption of accessibility by inspiring the local tech community with meetups and mentorship. When away from his computer, Raghava can be found at local cafes & restaurants sampling cuisines, attending local meetups, listening to audio books or writing on his Personal Blog.

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Get Digital A11Y in Your Inbox

Recent A11Y Articles

  • Understanding SC 4.1.2 Name, Role, Value
  • Understanding SC 4.1.1 Parsing
  • Understanding SC 3.3.4 Error Prevention (Legal, Financial, Data)
  • Understanding SC 3.3.3 Error Suggestion
  • Digital Accessibility Courses Roundup

A11Y Categories

  • Design
  • Events
  • HTML
  • IOS
  • Mobile Accessibility
  • News
  • Tools
  • WAI-ARIA
  • WCAG
  • Web Accessibility

  • Privacy Policy
  • Sitemap
© 2019 Digital A11Y