This Wiki page is edited by participants of the WCAG Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

Understanding 3.3.1

Revision as of 20:55, 4 October 2012 by Gvander (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The WCAG2ICT Task force requests WCAG WG to add text to the first paragraph of the intent for SC 3.3.1 as shown below. The reason for the addition is that it was unclear what exactly constituted an "input error" and what did not. Without the examples there was a very wide range of thought on what might be considered input error as it was intended in this success criterion. There was also a question as to whether or not the user needed to be alerted if they entered something out of range and the software automatically change their number to something that was in range. Since this arose as a question, we thought that this was important to document the answer.

Please modify the first paragraph of WCAG INTENT FOR SC 3.3.1 as follows.

<current Understanding WCAG 2.0 paragraph> The intent of this Success Criterion is to ensure that users are aware that an error has occurred and can determine what is wrong. The error message should be as specific as possible. In the case of an unsuccessful form submission, re-displaying the form and indicating the fields in error is insufficient for some users to perceive that an error has occurred. Screen reader users, for example, will not know there was an error until they encounter one of the indicators. They may abandon the form altogether before encountering the error indicator, thinking that the page simply is not functional. <end of current paragraph - start of requested addition>

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
  • information that is provided by the user but that falls outside the required data format or allowed values."

For example:

  • the user fails to enter the proper abbreviation in to state, province, region,etc field
  • the user enters a state abbreviation that is not a valid state
  • the user enters a non existent zip or postal code
  • the user enters a birth date 2 years in the future
  • the user enters alphabetic characters or parentheses into their phone number field that only accepts numbers
  • the user enters a bid that is below the previous bid or the minimum bid increment

NOTE: If a user enters a value that is too high or too low, and the coding on the page automatically changes that value to fall within the allowed range, the user's error would still need to be described to them as required by the success criterion. Such an error description telling the person of the changed value would meet both this success criterion (Error Identification) and success criterion 3.3.3 (Error Suggestion).

<end of requested addition>