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

[jake-abma]

There's a problem with 2 statements in 1 SC: 3.3.1: Error Identification when 1 is enough as sufficient (and in general for other SC too)

When there's a sufficient technique present for one part of a SC, the other part is neglected / not needed anymore, sadly making the SC weak.

See as an example: 3.3.1: Error Identification where a Sufficient technique is:

Using Aria-Invalid to Indicate An Error Field (but not mentioning anything about "and the error is described to the user in text."
https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA21

Also the use of ARIA here serves people using AT, but why is it sufficient for the complete SC?
Other users do not benefit from this Sufficient technique.

Like the functional need mentioned:

or colorblind to perceive the fact that an error occurred

Also here it should be advisory or the techniques need to be stacked as a set where the complete SC is covered from A-Z

[jake-abma]

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. Sufficient technique for 3.3.1: Error Identification:

Situation A: If a form contains fields for which information from the user is mandatory.
G83: Providing text descriptions to identify required fields that were not completed

4. Sufficient G83 Tests Procedure:

1. Fill out a form, deliberately leaving one or more required (mandatory) fields blank, and submit it.
2. Check that a text description is provided identifying the mandatory field(s) that was not completed.
3. Check that other data previously entered by the user is re-displayed, unless the data is in a security related field where it would be inappropriate to retain the data for re-display (e.g. password).

5. All pass and thus the SC passes!

6. Sadly, the Benefit of...:

"Providing information about input errors in text allows users who are blind or colorblind to perceive the fact that an error occurred."

...for the blind user is not fulfilled as the fact that the error is not consistently available (disappears after focus), also with screen reader on. (it is in the form list present, does that count? not all AT users use this option...)

[JAWS-test]

Error message at https://dequeuniversity.com/demo/dream: I would say that 3.3.1 is fulfilled, since error messages are present in text form. More is not required for 3.3.1. SC 1.3.1 is there to check whether all information can also be perceived with AT. This is not the case here, so I would consider this as a violation of 1.3.1

[jake-abma]

but it will pass 1.3.1 also...!

[JAWS-test]

Why?

[JAWS-test]

(disappears after focus)

This is a fail of 3.2.1 on focus

[JAWS-test]

Furthermore, using the value attribute for the error message would be a violation of 4.1.2

[jake-abma]

This is a fail of 3.2.1 on focus

Nope, it's not a major change...

[JAWS-test]

Nope, it's not a major change...

Error messages that are automatically hidden are a major change. It's not about the size, but about the relevance of the change

[jake-abma]

this is not considered a major change of content per definition, but surely not a "change of context."

[bruce-usab]

From the conversation on the call today, the focus has been about if alt text counts as text. Framing the question that way misses what 3.3.1 requires.

I agree with OP that ARIA21 satisfies error is identified but does not satisfy described to the user in text.

Likewise, using an IMG for error is identified is fine, but does not address described to the user in text because the ALT value will (presumably) provide descriptive identification of the error icon (and that there is an identified error) but does not describe the error.

The 3.3.1 requirement is that the error is described (in text)

[JulietteZenyth]

I came across this yesterday as well.

Understanding Error Identification (3.3.1) lists technique ARIA21 as sufficient. It is not an "AND" statement where this technique AND another must be used to meet the SC. This doesn't seem correct to me as ARIA21 has no requirements for (and does not provide) a visible error message. Reading through the test process for ARIA21 it says (emphasis added):

"For each form control that relies on aria-invalid to convey a validation failure:
Check that aria-invalid is not set to true when a validation failure does not exist.
Check that aria-invalid is set to true when a validation failure does exist.
Check that the programmatically associated labels / programmatically associated instructional text for the field provide enough information to understand the error."

So, the technique itself says there should also be a visible error message with enough information to understand the error.

I believe this technique should be moved to 1.3.1 because it is about programmatically providing the information, not about he visual display of the error message.