Nr. 2: Problem with 2 statements in 1 SC: 3.3.1: Error Identification

[jake-abma]

So the SC is in 2 pieces:

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

The AND suggests you need to do 2 things:

1. identifying the item in error
2. describe in text what the error is

First Question:
DOES the describing of the error in text already identifies the item?

• If so, is the first part of the sentence not always already a pass?
• If not, what situation is there where this is not true (example? they already need to be 'connected' somehow!))

Second Question:
If the text description and identification are separate things, what counts as 'identification' from a visual perspective?

• programmatic invalid state is clear, like ARIA-invalid etc., mentioned by screen reader
• visually all kind of solutions are out there, with for example the text "error" visible or hidden, with or without icon, border etc.

Third Question
Is the third example NOT correct, merging the two statements into 1 requirement?

Identifying errors in a form submission

An airline Web site offers a special promotion on discounted flights. The user is asked to complete a simple form that asks for personal information such as name, address, 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.

NOTE
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.

All is clear TILL THE NOTE... because it states:

• All color and text styles can be used in whatever way, do it your way, clear, BUT...
• Second it says "requires that errors also be identified using text" suggesting that the text is already identifying the item, see my First Question above... !
• Then... "two asterisks are used in addition to color" I think the color part can be skipped as this is an extra, but "two asterisks"... is that "describe in text what the error is"? Think not so it serves only as the 'identifier', first part of the SC.
• BUT..., the example says: "an alert is displayed notifying the user which field or fields were missing or incorrect.", isn't the "which field or fields" part not already identifying the fields? see my First Question above... !

So now an example from Deque Demo pages:

https://dequeuniversity.com/demo/dream

1. Click on "Search" without filling in anything
2. See the Error message "Please enter a station"
3. See that the text disappears after focus is set on an input

Fourth Question
Is the first text you see "Please enter a station" enough for identifying the input by describing the error if programmatically also connected to the input?

• catching both statements of the SC, and basically making the first statement redundant?

[mraccess77]

I asked some questions in the discussion feature of Github 23 days ago (at the recommendation of Alastair to use that feature) around this SC 3.3.1 but have had to response. #1726 My question is related to the wording of errors and whether they need to indicate that something is wrong rather than restarting what to do.

I've pasted it below:
SC 3.3.1 requires that you indicate the field in error and identify the error.

Say you have a field like the below that indicates required state:

required
First Name: Input
After submitting without a name it now adds "Please enter your name" which was not there previously. The text is associated with the form field programmatically.

required
First Name: Input
Please enter your name
Does the wording "Please enter your name" clearly communicate there is an error present? or Does there need to be some other wording such as "incomplete", "missing", or "error" to communicate to the user the field is in error?

If the text "please enter your name" were in red, would this make it more of an error under SC 1.4.1 as red makes it obvious to some there is an issue?

[JAWS-test]

First Question: DOES the describing of the error in text already identifies the item?

Yes, if the message is displayed at the field.
No, if the message is not displayed at the field, but e.g. in a pop-up or above the form. I have had to check many applications according to WCAG, where above the field it only said: "The value ... is incorrect" or "Fill in the required field", but the incorrect field was only highlighted in red. Here the incorrect field is not mentioned in text, which is a violation of 3.3.1

[JAWS-test]

I think the questions are superfluous if you read 3.3.1 the way I do (the question, of course, would be whether 3.3.1 is meant that way):

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.

is the short version of :

If an input error is automatically detected,

• the item that is in error is identified to the user in text
• and the error is described to the user in text

[mraccess77]

An example might be a First name field that has a label of first name. When the error appears for SC 3.3.1it adds some extra text below the field that is associated as says "Enter your first name" - basically restating the field without clearly saying there was something wrong. What I'm trying to figure out is if it needs to say that something was wrong - for example, "The first name field was left blank" or whether it needs to use some specific wording such as "invalid" or "error".

[jake-abma]

If an input error is automatically detected,

the item that is in error is identified to the user in text
and the error is described to the user in text

So the exact requirement is:

1. The item is identified by:
   1.1 OR using a text like 'error'
   1.2 OR using some sort of 'hint'
   1.3 OR Using some visual thingy like an icon, with a hidden SR text like 'error' (is a 'hint' here also enough?)
   1.4 OR referring to parts of the label in the 'error text'
2. All of the above "must be programmatically linked" to the item or always fail by default
3. The item in error is described to the user in text, and this means:
   3.1 A text description mentioning what to do ("Enter your first name")?
   OR
   3.2 A text description mentioning what error occurred ("The first name field was left empty")?

Sixth Questions:

1.2a. When a hint is enough, like an "asterisks" (see example in Understanding) does the explanation of the "asterisks" also need to be programmatically linked? (or no explanation needed?)

So, is the text "all fields with an 'asterisks' are required BUT a double 'asterisk' means the field is in error" enough by only being placed at the top of a form? (no programmatic association)

If the top of the form is enough, why do the others need to be "programmatically linked" to explain what happened where, if the text itself already must mention which item is in error? (maybe not requiring "2. All of the above "must be programmatically linked""?)

1.2b What counts as a "hint"? A double 'asterisks' only? (I have never seen them!) Others?

@mraccess77
3. What text is sufficient for 3.3.1?
3.a "Enter your first name"
3.b "The first name field was left blank"
3.c "Error: the first name field is required but left blank, please enter your first name here"

[jake-abma]

Ow yeh, when using a visual icon AND Aria-invalid, the item is NOT identified in text !!! (it serves as an equivalent for AT users, but technically it's not text provided by the author, unless we stretch what text is and count attributes as text too, which direction I do not think we should go!)

[patrickhlauke]

x-ref #1651

[JAWS-test]

All of the above "must be programmatically linked" to the item or always fail by default

In my opinion this is not relevant for SC 3.3.1, but for 1.3.1

[patrickhlauke]

agree, programmatic linking is 1.3.1, not related to 3.3.1. i thought i had that as well in my PR #1651 but it appears not. will backfill (edit: done (https://github.com/w3c/wcag/pull/1651/files#diff-7ab9dda99450b42951e62a63fb7f6fff1783fcb67381d09992ff71ad5275d1d4R78)

[bruce-usab]

If so, is the first part of the sentence not always already a pass?

No. For example, an error message could just be you did not fill in all required fields. If so, that does meet item that is in error is identified. These sort of vague error messages used to be pretty common.

If the text description and identification are separate things, what counts as 'identification' from a visual perspective?

Agreed, pretty wide latitude on this. So 3.3.1 is requiring that there be explicit identification, but the visual formatting of that identification is very open. (And yes, they are separate things.)

[gjccopinga]

I asked some questions in the discussion feature of Github 23 days ago (at the recommendation of Alastair to use that feature) around this SC 3.3.1 but have had to response. #1726 My question is related to the wording of errors and whether they need to indicate that something is wrong rather than restarting what to do.

I think there should be a clear distinction between instructions and error messages. My understanding is that SC 3.3.1 asks for error messages and not instructions (after submit). So, if there are only instructions or browser messages like "This field is mandatory" it is a fail.

required First Name: Input Please enter your name Does the wording "Please enter your name" clearly communicate there is an error present? or Does there need to be some other wording such as "incomplete", "missing", or "error" to communicate to the user the field is in error?

A message "Please enter your name" is an instruction and not an error message. It does not clearly communicate there is an error present. For me, this is a fail. You can use this as an addition to an error message but not as a replacement of an error message.

If the text "please enter your name" were in red, would this make it more of an error under SC 1.4.1 as red makes it obvious to some there is an issue?

Just using color to indicate it is an error message is nog sufficient in my opinion. You could use an icon (with an appropriate alt text), but not color alone.

Instead of "Please enter your name" I would use something like "The field 'Name' was left blank" or "The field 'name' is empty". Of course you could add an additional instruction. Something link "The field 'name' is empty. Please enter your name".

So, for me an instruction message after a submit is not a good error message. Instructions ar only good or usefull as an addition to, in basic, a real error messages (that tells you what went wrong in an explicit way and not indirect).

I wonder if my interpretation above is the right one.

[mraccess77]

I agree that an error needs to indicate that something is wrong. It doesn't need to specifically use the word error - but it needs to indicate more than "enter your name" it needs to say that the name was missing, empty, or the field is required, or that there was an error and what the error was.

[patrickhlauke]

I think we might be getting lost in the nuances of subjectivity, language, and tone (which is always fun for a binary pass/fail SC). some people will say "Please enter your name" is a very polite, albeit slightly indirect, way of indicating there was an error and instruction on how to fix it. others clearly disagree. and I doubt we'll find some kind of definitive way of clearly explaining, in unambiguous language, where to draw the line here (not even going to go down the path of potential cultural differences, different audiences, nuance of different languages, etc)

[gjccopinga]

I understand that this is a slippery slope to walk on. But we do need some sort of guideline on how to deal with this. Our rule of thumb is the following: If it is something that could have been there before the form was submitted (as is the case with instructions) it is not really an error message. So something like "Please enter your name" is something that can be shown before submitting. It is a good label or instruction (as for 3.3.2). But something like "The name field is empty" is not logical to put in before submitting the form. For us, even a message like "This field is required" or "The name field is required" is not a real error message, because it is an instruction that could have been placed before submitting the form (and usually already is either in text or with an asteriks character). This is for us the easiest way to instruct all our testers to make the same call on pass or fail.