apart from possibly a bit of a rewording/focusing of the understanding, this could also really do with a few good representative examples (in case there are multiple scenarios here that are deemend appropriate, like a form with a list of errors at the start, and form fields then just identified with an icon/color; and, if acceptable as a solution, a form where each form field that is in error has an inline/contextual text-based error message showing, but NO list of errors at the start; etc)

to clarify the question, here's an example of what i mean by "in context" text-based error messages. a user tries to register an account and leaves out fields. fields are denoted both with an icon AND with text adjacent to the relevant form field, indicating there's an error with a particular field. there is no overarching "there were errors" / "here's a list of errors" or similar type separate listing/notification.

if this is deemed acceptable (which has been my interpretation until now), then how does that square against this part of the intent

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.

because screen reader users will also not know there was an error until they encounter the text-based indicators (unless we don't include the text-based errors as "indicators" - but even then, they wouldn't know there were errors until they encountered the text-based error descriptions)

and, to address the specific "SR users don't know that there was an error when hitting submit", isn't the solution more about moving focus, firing a status message, or similar? not really directly related to text-based error descriptions?

looking over one of the techniques (https://www.w3.org/WAI/WCAG21/Techniques/general/G83) there's a suggestion:

Another approach, using server-side validation, is to re-display the form (including any previously entered data), with either a text description at the location of the omitted mandatory field, or a text description that identifies the omitted mandatory fields.

leaving aside that this can also be done client-side, this seems to suggest that having "inline" text-based errors is fine. but again, that would go against the stated scenario of SR users missing these errors until they encounter them again.

From reading the sufficient techniques my understanding is that this can be met by a list at the top of the form or with inline error messages, or with an alert dialog. Linking the messages at the top with the fields is only advisory but best practice.

so the too long;didn't read is the basic "there needs to be some error indication/notification/list/description that uses text - not just image-based indicators (like a warning triangle, red X, or similar) even if they have appropriate alternative non-visible text"?

and everything else (the idea that having an overarching error message, or even a list of errors, at the start of the form; or somehow firing an altert/moving focus back to the start of the form/to the first erroneous form field) that's mentioned later on/interspersed in the understanding doc is just additional optional nice-to-have stuff?

@patrickhlauke I think icons could be used if they had alt text and didn't rely on color and the icon communicated the field in error. The challenge is when combined with error suggestions I may be difficult to provide both error identification and suggest as icons alone.

I think icons could be used if they had alt text

That isn't my reading of this SC ... I'm not sure we claim that images with alt count as "described to the user in text"

and didn't rely on color

well that's a 1.4.1 use of color issue, related but not pertinent here

I find SC 3.1.1 + Understanding too vague to pinpoint what is required here. Another problem is that there are currently no Failures. I think the quoted screen reader section ("Screen reader users, for example, will not know there was an error ") could be removed because it's now covered by SC 4.1.3.
Then a description in text form at the field or elsewhere would certainly be sufficient. If elsewhere, it would certainly be necessary to name the faulty fields.
The question is, if an error message has to be linked to the field (e.g. with aria-describedby) or if it falls under 1.3.1 or if this is not required ...?

I agree with the theme that error messages need to be in text, and you have options about how that is done.

With clients, I try to pin down whether it is a 'traditional' form that you submit and then get the errors, or is it a dynamic form which displays errors as you go along.

The 'vagueness' is necessary (unless we make it very long) as there are diffrent approaches depending on how the form works. E.g. if you submit the form and start at the top of the page then the top-of-page errors works well (with some indicator next to the input as well). However, if it is more dynamic, then by the input is the better option, perhaps with a message prior to the submit button.

If someone would like to add some examples or do an update, please assign this to yourself and create a doc or PR.

I'd like to come to a consensus if only providing the errors in text at the top of the form without a text indication next to the field or link to the field is a violation. Making sure we are passing/failing consistently is important to trustworthiness of our industry.

providing the errors in text at the top of the form without a text indication next to the field or link to the field is a violation

I wouldn't draw that conclusion from the SC text as written, and there are circumstances where a text error mesage at the top might be more useful. At the moment we fail for lack of a text-error message, but it could be at the top or next to the input.
If a form is dynamically adding error messages at the top (away from the focus) I'd start bringing up Status Messages, but generally advise that the solution for dynamically added error messages is to put them after the input, with a message prior to submission.

Coming back to this (revisiting some of my long-open issues), are we roughly in agreement that this sentence in the intent is just making matters more confusing?

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.

as this implies that there needs to be extra stuff, like an alert dialog, status notification, list of errors or a message that "there were errors" or similar, and that this goes beyond what the requirement of the SC itself is? it's a best practice perhaps, but not core to the ask of the SC?

made a first stab at a rewording/refocusing of the understanding document based on what i believe is mostly agreement in this discussion #1651