Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update/correct 3.3.1 understanding #1803

Merged
merged 5 commits into from
Feb 27, 2024
Merged

Update/correct 3.3.1 understanding #1803

Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
f3e80a1
Update/correct 3.3.1 understanding
patrickhlauke May 11, 2021
b0c5c33
Remove the unnecessary reference to the definiton "in WCAG"
patrickhlauke May 11, 2021
67ea675
Add ARIA2 to sufficient techniques
patrickhlauke May 11, 2021
7f37a50
Merge branch 'main' into patrickhlauke-understanding-errors
patrickhlauke Feb 19, 2023
2495b86
Update understanding/20/error-identification.html
patrickhlauke Feb 13, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 11 additions & 8 deletions understanding/20/error-identification.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,12 +16,12 @@ <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
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 in WCAG 2.0, an "input error" is information provided by the user
that is not accepted. This includes:
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>

<ul>
Expand Down Expand Up @@ -72,21 +72,18 @@ <h2>Intent of Error Identification</h2>
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.
Currently, few technologies support this kind of programmatic information, but the
Success Criterion does not require, nor prevent it.

This type of programmatic information is not required for this success criterion, but is covered
by other criteria such as <a href="#name-role-value">4.1.2 Name, Role, Value</a>.
patrickhlauke marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

@detlevhfischer detlevhfischer Feb 19, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea of 3.3.1 is: ALL users should know that some error has occured. We have always thought it appropriate to cover missing programmatic linking of error messages, and programmatic identification of required state where indiated visually, under 3.3.1 since it is an aspect of the use case of realising that there has been an error. Is the added reference to 4.1.2 meant to indicate that that kind of error should be reported in 4.1.2 and not here? If so, that is not explicit now. I guess programmatic identification of errors might possibly be done in several ways (programmatically moving focus to the message?) that would not necessarily fall under 4.1.2. Another way would be 4.1.3, which is not referenced here - I guess it should be, by analogy.

I can see the advantage of covering aspects of bad errror handling under other SCs: 4.1.2 (messages not programmatically referenced) 1.3.1 ('required' indicated only visually), 1.3.2 (error message appears above the field), 4.1.3 (error status message not programmatically available) - BUT from the point of use of an audit report, this means the issues around error handling are widely dispersed across the report. I'm OK with that (because what it changes is nothing substantial, but only the allocation of errors to SCs), but I wonder if at least the programmatic availability of error messages is something that can usefully be reported under 3.3.1 (because it does not concern so much the value / state of a UIC but the availability / identification of the result of a user interaction).

Copy link
Contributor

@mbgower mbgower Feb 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is parallel to the way that 2.4.6 covers whether headings exist, but 1.3.1 would cover whether they are programmatically indicated as headings. It would be incorrect to fail 2.4.6 if someone used <p><strong>How to interpret 3.3.1</strong></p> instead of <h2>How to interpret 3.3.1</h2>, but it would not pass 1.3.1.

Likewise, injecting <p>The Name field is required</p> into the form after an attempt at submission would pass 3.3.1 (via G83: Providing text descriptions to identify required fields that were not completed), and I do not think you would get consensus that it fails either 1.3.1 or 4.1.2, although I think you would on it failing 4.1.3.

Finally it is fairly clearly established that we do not create a catalog of ways something could fail other SCs in the Understanding documents. I think the balance created here is reasonable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finally it is fairly clearly established that we do not create a catalog of ways something could fail other SCs in the Understanding documents. I think the balance created here is reasonable.

Yes, I see the point in that. But my point was that there are reasons to fail unreferenced error messages here, in 3.3.1, as this cannot easily be captured under 4.1.2 (it is not narrowly a name, role or value of an UIC that is at fault) and arguably 1.3.1 is met if output is available in browse mode. And it is an accessibility issue that should be captured somewhere - why not here?

I am not in the way of progressing this PR without such addition, though, and to create a separate PR for it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, please open a new issue/PR to address your concerns.

</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>


</section>
<section id="benefits">
<h2>Benefits of Error Identification</h2>
Expand Down Expand Up @@ -191,6 +188,12 @@ <h4>Situation A: If a form contains fields for which information from the user i
<a href="https://www.w3.org/WAI/WCAG21/Techniques/general/G83" class="general">Providing a text description that identifies the field as mandatory</a>

</li>

<li>

<a href="https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA2" class="aria">ARIA2: Identifying required fields with the "required" property</a>

</li>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • In subsection "Sufficient Techniques for Error Identification" there are several empty list items / links that should probably be removed.
  • There are two empty sections, "Resources for Error Identification" and, under "Techniques for Error Identification", "Failures for Error Identification". I guess these should be removed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

those were parts of the file i hadn't touched, and looking at the live version, it seems the xslt/publish script silently removes there. happy to rip them out of the file itself ...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with patrick, I think this is actually just a case where the preview rendering is inaccurate. This happens because some of the links here are written in the source like this:

               <li>

                  <a href="https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA21" class="aria"></a>
                  
               </li>

...which looks like empty list items as rendered by the preview, but when processed to build the live version, actually results in the <a> elements getting filled in using the title of the page (you can see an "ARIA21" link like the above example correctly in the rendered live page)


<li>

Expand Down