Rewrite for 3.3.1 Error Identification understanding document

[patrickhlauke]

• 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

[mraccess77]

I like the updates! I agree for a login form that additional error for an empty field is not required as in a simple form it is assumed these two fields are required.

[mraccess77]

For the last bullet where a field is already marked required - if the field is using an asterisk and the asterisk is described at the top of the form as indicated a required field are we now saying nothing else needs to be said/done - so when the user submits the form with a missing required field the focus could just stay on submit and no visual changes need to take place? I just want to make sure we have thought of all situations.

[patrickhlauke]

For the last bullet it's saying that error still needs to be indicated, but a redundant additional explanation in text may not be needed.

There may also be situations in which it is clear from the context what the specific error
is - for instance, in a simple login form with a username and password field, if a user
leaves one of the fields completely blank, simply indicating that the empty field is in
error using an image or icon (with appropriate alternative text) would be sufficient.

i.e. no need to have a field that was marked as required, after failing has now an additional indication (like a warning triangle)...i'd argue there's no point now also requiring a repetitious and not very informative "You must fill in this required field" just to satisfy the "error is described in text".

[bruce-usab]

FWIW, I have always understood that described to the user in text is a very low bar. It excludes the most egregious barriers, for example, adding (only) a red border (around the error) or (only) a warning triangle. But it can be helpful to be able to fail situations similar to those two not-uncommon error indicators (even when they they pass 1.4.1 and 1.1.1), and 3.3.1 provides that.

[mraccess77]

I believe it's reasonable that login forms should not have to have required field indicators as by nature of authentication you have to enter a username and password. However, upon submitting without entering one or the other or invalid content then I'd expect some sort of error message to then be required.

[patrickhlauke]

I'd expect some sort of error message to then be required

but for those situations where it's quite clear from context (e.g. of course you can't log in with only a username and not providing a password), does the error absolutely need to be conveyed in text, or is it then sufficient to provide an error indication (which could be just an icon or similar - provided it passes other SCs like 1.1.1, 1.4.11, etc) without the need for words? that's the circle i was trying to square here with some nuance/human judgement.

[mraccess77]

I personally think an icon that indicates missing field with alt text is sufficient when combined with the implicit or explicit required state.

[patrickhlauke]

I see this has a SurveyAdded tag. what was the outcome of the survey? lost track of this... @alastc

[dbjorge]

@gundulaniemann @patrickhlauke I think your discussion about whether the understanding doc should include an example of whether a login form needs to clarify whether username vs password was incorrect is a good discussion and something that it'd be helpful to add an example for, but probably out of scope for this PR. I think existing issue #2175 covers this already (the title says 3.3.3 but the discussion/labels clarify that it's scoped to both 3.3.3 and 3.3.1)

[mbgower]

I don't think I agree with this. 3.3.1 Error Identification specifically requires that "the error is described to the user in text." An image or an icon is not text.
IMO the error must be described in text to pass the SC. I recommend deleting the sentence formed at lines 28 and 29

In regard to the prior discussion on what is sufficient with a simple username/password field, IMO a symbol on a field would not be sufficient. It would need at a minimum something saying "Supply a username" or "The field requires a value" or "Missing value", etc

[patrickhlauke]

i'll admit that, since it's been over 3 years since i wrote most of this...i can't quite recall where that phrasing i suggested came from. i'm fairly sure it bubbled up from related discussions mentioned here. (that's the joy of revisiting really old PRs)

not particularly wedded to any of these wordings at the moment, just trying to address some of the other more dramatic issues listed in the description bullets here

[mbgower]

@patrickhlauke I have made a suggested change which makes the need for text explicit. I'd like to revert to this, then open up a separate issue to directly address whether there is support to allow only a symbol with alt in specific circumstances.
If that works for this PR, please incorporate. Also, I struck through a bullet in the initial PR comment which lists this. Feel free to remove if you agree.

[patrickhlauke]

accepted the changes that removed the suggestion that images with appropriate alt would be sufficient. would still love to qualify somewhere/somehow that in some cases, existing text (like already having "required" clearly stated in the label) coupled with an additional indicator (which could just be an extra icon or similar) could pass ... as there seems to be at least partial agreement that these situations do exist and that this is indeed acceptable, rather than having to have very explicit extra text. at least in practice this is what we see a lot out there. and then the classic case of a form that, contextually, of course requires both fields ... where just having an icon like a warning triangle (e.g. on a username/password login, and you leave one blank) on the empty one would probably be sufficient hint. but i'll leave this for another SC. see if this now makes sense, with that aspect left out for now...

[mbgower]

accepted the changes that removed the suggestion that images with appropriate alt would be sufficient. would still love to qualify somewhere/somehow that in some cases, existing text (like already having "required" clearly stated in the label) coupled with an additional indicator (which could just be an extra icon or similar) could pass ... as there seems to be at least partial agreement that these situations do exist and that this is indeed acceptable, rather than having to have very explicit extra text. at least in practice this is what we see a lot out there. and then the classic case of a form that, contextually, of course requires both fields ... where just having an icon like a warning triangle (e.g. on a username/password login, and you leave one blank) on the empty one would probably be sufficient hint. but i'll leave this for another SC. see if this now makes sense, with that aspect left out for now...

I have added this as a consideration for WCAG 3 https://github.com/w3c/wcag/wiki/WCAG-3-parking-lot-considerations-from-2.x

One was addressed; the other was not part of the changes in this PR.