Skip to content

Commit

Permalink
Rewrite for 3.3.1 Error Identification understanding document (#1651)
Browse files Browse the repository at this point in the history 
* remove the misleading statement about screen reader users needing to
know that an error occurred before hitting one of the indicators/fields.
this implicitly suggests that the intent is for an error message/list to
be shown to (screen reader) users before the actual form, which is not
in fact the intention nor the requirement of this SC
* tweak the benefit for users with cognitive/language/learning
disabilities
* refocus on the benefit to ALL users, not just screen reader users
* ~add allowance for situations where an error indication is already
self-explanatory/obvious from context (e.g. a form where fields have
already explicitly been identified as mandatory/required - not necessary
for compliance to now ALSO explicitly say "as we already told you, this
field is mandatory")~ [potentially removed by mbgower suggestion]

Closes #977

---------

Co-authored-by: Alastair Campbell <ac@alastc.com>
Co-authored-by: Mike Gower <gowerm@ca.ibm.com>
Co-authored-by: Wilco Fiers <WilcoFiers@users.noreply.github.com>
Co-authored-by: Mike Gower <mikegower@gmail.com>
  • Loading branch information
@patrickhlauke @alastc
@mbgower @WilcoFiers
5 people committed May 14, 2024
1 parent 619aa18 commit 3cf31a0
Showing 1 changed file with 83 additions and 198 deletions.
281 changes: 83 additions & 198 deletions understanding/20/error-identification.html
View file
Original file line number Diff line number Diff line change
@@ -1,124 +1,103 @@
<!DOCTYPE html>
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="UTF-8"></meta>
<meta charset="UTF-8"/>
<title>Understanding Error Identification</title>
<link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove"/>
</head>
<body>
<h1>Understanding Error Identification</h1>

<section id="brief">
<h2>In brief</h2>
<dl>
<dt>Goal</dt><dd>Users know an error exists and what is wrong.</dd>
<dt>What to do</dt><dd>Provide descriptive notification of errors.</dd>
<dt>Why it's important</dt><dd>Flagging errors helps people with reduced sight and cognitive disabilities resolve them.</dd>
<dt>Why it's important</dt><dd>Flagging errors helps people with reduced sight and cognitive disabilities resolve them.</dd>
</dl>

</section>

<section id="intent">
<h2>Intent of Error Identification</h2>


<p>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. Per the definition,
an "input error" is information provided by the user that is not accepted. This includes:

<p>The intent of this success criterion is to ensure that users are aware that an error
has occurred and can determine what is wrong. In the case of an unsuccessful form submission,
it is not sufficient to only re-display the form without providing any hint that the submission
failed.
The error must be indicated in <a>text</a>.
Whether or not an error message provides users with sufficient information about the nature of
the error, and what they should do to correct it, is covered more specifically by
<a href="error-suggestion">3.3.3 Error Suggestion</a>.
</p>

<p>An "input error" is information provided by the user that is not accepted. This includes:</p>

<ul>

<li>information that is required by the web page but omitted by the user, or</li>

<li>information that is provided by the user but that falls outside the required data
format or allowed values.
</li>

<li>information that is provided by the user but that falls outside the required data format or allowed values.</li>
</ul>

<p>For example:</p>

<ul>

<li>the user fails to enter the proper abbreviation in to state, province, region, etc.
field;
</li>

<li>the user fails to enter the proper abbreviation in a state, province, or region field;</li>
<li>the user enters a state abbreviation that is not a valid state; </li>

<li>the user enters a non existent zip or postal code;</li>

<li>the user enters a birth date 2 years in the future;</li>

<li>the user enters alphabetic characters or parentheses into their phone number field
that only accepts numbers;
</li>

<li>the user enters alphabetic characters or parentheses into their phone number field that only accepts numbers;</li>
<li>the user enters a bid that is below the previous bid or the minimum bid increment.</li>

</ul>

<div class="note">

<p>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
<a href="error-suggestion" class="understanding">Success Criterion 3.3.3 (Error Suggestion)</a>.
Identification) and <a href="error-suggestion">3.3.3 Error Suggestion</a>.
</p>

</div>

<p>The identification and description of an error can be combined with programmatic information
that user agents or assistive technologies can use to identify an error and provide
error information to the user. For example, certain technologies can specify that
the user's input must not fall outside a specific range, or that a form field is required.
This type of programmatic information is not required for this success criterion, but may be covered
by other criteria such as <a href="#name-role-value">4.1.2 Name, Role, Value</a>.
</p>

<p>It is perfectly acceptable to indicate the error in other ways such as image, color
etc, in addition to the text description.
</p>

<p>See also
<a href="error-suggestion">3.3.3: Error Suggestion</a>.
</p>

Currently, few technologies support this kind of programmatic information, but this
success criterion does not require, nor prevent it.</p>

<p>It is perfectly acceptable to indicate the error in other ways such as through the use of an image,
color, or other visual indicator, in addition to the text description.</p>

<div class="note">
<p>This criterion does not mandate any particular way in which errors should be displayed. Depending
on the situation, it may be more suitable for all errors to be listed at the start or before a form.
In other cases, it may be more appropriate to show errors inline, with error messages next to the specific
fields that are in error. Errors could also be listed in an alert, or dialog. This criterion does not
cover which of these methods should be used - the only requirement is for errors to be presented to users in text or a text alternative.
</p>
</div>

<p>See also <a href="error-suggestion">3.3.3: Error Suggestion</a>.</p>

</section>
<section id="benefits">
<h2>Benefits of Error Identification</h2>



<ul>

<li> Providing information about input errors in text allows users who are blind or colorblind
to perceive the fact that an error occurred.
<li>
Providing information about input errors in text allows users who are blind or color deficient (color blind) to perceive the fact that an error occurred.
</li>

<li>
This Success Criterion may help people with cognitive, language, and learning disabilities
who have difficulty understanding the meaning represented by icons and other visual
cues.


This success criterion may help people with cognitive, language, and learning disabilities
who have difficulty understanding the specific reason why a form submission failed (in cases
where this is not already made obvious by the nature of the form).
</li>

</ul>

</section>

<section id="examples">
<h2>Examples of Error Identification</h2>

<dl>
<dt>Identifying errors in a form submission</dt>
<dd>
Expand All @@ -127,11 +106,10 @@ <h2>Examples of Error Identification</h2>
phone number, seating preference and e-mail address. If any of the fields of the form
are either not completed or completed incorrectly, an alert is displayed notifying
the user which field or fields were missing or incorrect.</p>

<div class="note">
<p>This Success Criterion does not mean that color or text styles cannot be used to indicate
errors. It simply requires that errors also be identified using text. In this example,
two asterisks are used in addition to color.
<p>This success criterion does not mean that color or text styles cannot be used to indicate
errors. It simply requires that errors also be identified using text.
</p>
</div>
</dd>
Expand All @@ -140,159 +118,66 @@ <h2>Examples of Error Identification</h2>
and providing a unique character to make it easy to search for the fields, the fields
are highlighted in yellow to make it easier to visually search for them as well.</dd>
</dl>

</section>

<section id="resources">
<h2>Resources for Error Identification</h2>




</section>

<section id="techniques">
<h2>Techniques for Error Identification</h2>



<section id="sufficient">
<h3>Sufficient Techniques for Error Identification</h3>



<section class="situation" id="error-identification-situation-0">

<h4>Situation A: If a form contains fields for which information from the user is mandatory.</h4>

<ul>

<li>

<a href="../Techniques/general/G83" class="general">Providing a text description that identifies the field as mandatory</a>

</li>

<li>

<a href="../Techniques/aria/ARIA2" class="aria">ARIA2: Identifying required fields with the "required" property</a>

</li>

<li>

<a href="../Techniques/aria/ARIA21" class="aria"></a>

</li>

<li>

<a href="../Techniques/client-side-script/SCR18" class="script">Providing client-side validation and alert </a>

</li>

<li>

<a href="../Techniques/pdf/PDF5" class="pdf"></a>

</li>

<li><a href="../Techniques/general/G83" class="general">Providing a text description that identifies the field as mandatory</a></li>
<li><a href="../Techniques/aria/ARIA2" class="aria">ARIA2: Identifying required fields with the "required" property</a></li>
<li><a href="../Techniques/aria/ARIA21" class="aria"></a></li>
<li><a href="../Techniques/client-side-script/SCR18" class="script">Providing client-side validation and alert </a></li>
<li><a href="../Techniques/pdf/PDF5" class="pdf"></a></li>
</ul>

</section>

<section class="situation" id="error-identification-situation-1">

<h4>Situation B: If information provided by the user is required to be in a specific data
format or of certain values.
</h4>

<ul>

<li>

<a href="../Techniques/aria/ARIA18" class="aria"></a>

</li>

<li>

<a href="../Techniques/aria/ARIA19" class="aria"></a>

</li>

<li>

<a href="../Techniques/aria/ARIA21" class="aria"></a>

</li>

<li>

<a href="../Techniques/general/G84" class="general">G84: Providing a text description when the user provides information that is not in
the list of allowed values
</a>

</li>

<li>

<a href="../Techniques/general/G85" class="general">Providing a text description when user input falls outside the required format or
values
</a>

</li>

<li>

<a href="../Techniques/client-side-script/SCR18" class="script">Providing client-side validation and alert</a>

</li>

<li>

<a href="../Techniques/client-side-script/SCR32" class="script">Providing client-side validation and adding error text via the DOM</a>

</li>

<li>

<a href="../Techniques/pdf/PDF22" class="pdf"></a>

</li>

<li><a href="../Techniques/aria/ARIA18" class="aria"></a></li>
<li><a href="../Techniques/aria/ARIA19" class="aria"></a></li>
<li><a href="../Techniques/aria/ARIA21" class="aria"></a></li>
<li><a href="../Techniques/general/G84" class="general">G84: Providing a text description when the user provides information that is not in the list of allowed values</a></li>
<li><a href="../Techniques/general/G85" class="general">Providing a text description when user input falls outside the required format or values</a></li>
<li><a href="../Techniques/client-side-script/SCR18" class="script">Providing client-side validation and alert</a></li>
<li><a href="../Techniques/client-side-script/SCR32" class="script">Providing client-side validation and adding error text via the DOM</a></li>
<li><a href="../Techniques/pdf/PDF22" class="pdf"></a></li>
</ul>

</section>

</section>

<section id="advisory">
<h3>Additional Techniques (Advisory) for Error Identification</h3>



<ul>

<li>

<a href="../Techniques/general/G139" class="general">G139: Creating a mechanism that allows users to jump to errors</a>

</li>

<li>

<a href="../Techniques/general/G199" class="general">Providing success feedback when data is submitted successfully</a>

</li>

<li><a href="../Techniques/general/G139" class="general">G139: Creating a mechanism that allows users to jump to errors</a></li>
<li><a href="../Techniques/general/G199" class="general">Providing success feedback when data is submitted successfully</a></li>
</ul>

</section>

<section id="failure">
<h3>Failures for Error Identification</h3>



</section>

</section>

</body>
</html>

0 comments on commit 3cf31a0

Please sign in to comment.