• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
Logo for DigitalA11Y

Digital A11Y

Your Accessibility Partner

  • About
    • Bio
      • Conference Speaking
      • Videos
      • mentions
  • Articles
  • Resources
    • WAI-ARIA
    • WCAG
    • Cheat Sheets
    • A11Y Blogs
    • A11Y Toolkit
  • Contact
You are here: Home / Web Accessibility / WCAG / Understanding SC 3.3.1 Error Identification

Understanding SC 3.3.1 Error Identification

Last Modified: August 8, 2019 by Raghavendra Satish Peri 1 Comment

3.3.1 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. (Level A)

Web is built with multiple components. One of the components to collect the data from the users is forms. When the data entered into these forms don’t meet the requirements of the website the user must be provided with clear way to identify where the error is & should be guided to fix it accordingly. This success criterion states that errors must be presented in text. That doesn’t mean we cannot use other methods of alerting the users that forms failed validation. We can use images, symbols, color in addition to text errors.

The errors presented to the user should be as specific as possible so that users can take necessary action to fix it. A generic error that “this field is required” will not cut out for a lot of disable users. If a form control needs a specific format then it needs to be provided as an instruction to the user before the form is filled or it also can be mentioned in the error message when it fails validation.

Per the definition in WCAG 2.0, an “input error” is information provided by the user that is not accepted. This includes:

  • Information that is required by the web page but omitted by the user, or
  • Information that is provided by the user but that falls outside the required data format or allowed values.

Points to Remember

  • Make sure that errors are in text.
  • Don’t just use color or visual cues to point out form errors.
  • Use aria-describedby to bind the form control with the error programmatically.
  • Don’t disable the submit button! Some websites disable the submit button & will only enable it if the form is filled appropriately. This is bad practice.
  • Provide necessary instructions & be as specific as possible with the errors so that users can take necessary action.
  • Make sure that errors are distinguished from the regular text on the web page.

Building accessible forms is a complex topic. There are various ingredients involved to build an inclusive form. Here is a series of articles that will guide you through the process of building accessible forms

  • Accessible Forms & Problem with Placeholders
  • Accessible Forms & Required Fields
  • Best Practices for building Accessible Forms
  • Handling Errors in Accessible Forms

References

Understanding Success Criterion 3.3.1

Share A11Y Love

  • Twitter
  • LinkedIn
  • Facebook
  • Reddit

More Accessibility Articles

Filed Under: WCAG

About Raghavendra Satish Peri

Raghavendra Satish Peri is a digital accessibility evangelist working at Deque Systems as Product Manager [Accessibility]breaking web accessibility & mobile accessibility challenges. He authors an Accessibility Blog at DigitalA11Y.com & is galvanizing the adoption of accessibility by inspiring the local tech community with meetups and mentorship. He propelled this thought by founding HelloA11y.com, a community of accessibility professionals, developers and enthusiasts. 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 at raghava.in.

Reader Interactions

Comments

  1. Vaibhav Mishra says

    April 6, 2021 at 2:34 am

    Hi Raghvendra,

    Could you please little bit elaborate on how it is bad practice “Don’t disable the submit button! Some websites disable the submit button & will only enable it if the form is filled appropriately. This is bad practice.”

    Reply

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

  • WCAG 2.1 Checklist
  • A Sneak peek into WCAG 3.0 First Public Draft
  • Understanding SC 4.1.3 Status messages
  • Understanding SC 2.5.4 Motion Actuation
  • Understanding SC 2.5.3 Label in Name

Recent Comments

  • Isaac Williams on Digital Accessibility Companies Roundup
  • Vaibhav Mishra on Understanding SC 3.3.1 Error Identification
  • Vaibhav Mishra on Understanding SC 1.3.2 Meaningful Sequence
  • Donal Rice on Digital Accessibility Companies Roundup
  • Rajath on A Sneak peek into WCAG 3.0 First Public Draft

A11Y Categories

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

  • Privacy Policy
  • Sitemap
© 2021 Digital A11Y