Form / Input Errors Vs. states Vs. 1.4.11 Non-text Contrast Vs. 2.4.11 Focus Appearance (Minimum)

[jake-abma]

Error messages for forms need multiple outcomes for people to make it accessible.
Now I'm just wondering a bit about the complete coverage within WCAG for some outcomes...

1. Does an input error result in a "state"? I think it is, but it's not mentioned at the definition of "State", if agreed maybe good to add?

https://www.w3.org/TR/WCAG22/#dfn-states

state
dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes

States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collapse.

2. Do errors need a "2.4.11 Focus Appearance (Minimum) like" Success Criteria?

An error notification may consist of an indicator (like a red line around the input), an icon (error icon), error text (inside a clear 'box' / 'area with indication'?). The first 2 are covered by 1.4.11 Non-text Contrast, (an icon is not required per se,) but not the difference with the "before state". So do we have a small gap here in WCAG for error messages / states to be sure they 'pop out' clearly enough for all people, just like we have the 2.4.11 Focus Appearance (Minimum) now? Or is the opinion these cases are all already covered?

[jake-abma]

(in other words, Error Appearance (Minimum) needed?)

[patrickhlauke]

for 1., i'd say yes being "invalid" (in the case of erroneous form controls) is a state.

the definition of state only gives examples, so the current list (focus, hover, select, press, check, visited/unvisited, and expand/collapse) is not meant to be exhaustive. It could of course have more added (best to do at this stage, as doing a normative change later after publication would be a painful process). Suggest adding further examples of disabled, invalid. I'd also say the existing list could do with some normalisation to make sure they're all adjectives - focused, hovered, selected, pressed, checked.

for 2., i'd say also consider 1.4.1 Use of Color for the "is the change from other state visible enough" (e.g. in case of an underline or border that changes from gray to red or something). don't think personally that there should be a need for any particular SC that defines how "visible"/"noticeable" errors need to be, beyond the other SCs that cover visual aspects. otherwise we get into needing to normatively define how much of a visual change is normatively required to count as a "visible" error message/notification, which sounds like a painful and subjective exercise.

[bruce-usab]

Please consider the historical context, scoping to a UIC, and possible unintended consequences of expanding the definition of a rather fundamental term.

It is perfectly reasonable to talk about a form or app reporting an error state. (Or the form/app being in an error state.)

That use of the word state is different than the WCAG 2.1 glossary definition, and not how the term is used in 4.1.2.

Buttons/UIC can be checked or unchecked. Buttons/UIC can be pressed or not-pressed. I agree that disabled/unavailable is a significant omission from the current list of example states.

But what would it mean for a button/UIC to be error/not-in-error ?

[patrickhlauke]

this isn't attempting to expand the definition, it's just giving more examples. an being invalid (e.g. aria-invalid) is a state of some UICs. sure, not all of them can be invalid. but then again, not all of them can be checked/unchecked/pressed/visited/expanded/collapsed. the nuance is already there in the definition as it currently stands, those states may not apply to every possible UIC

[jake-abma]

@patrickhlauke I kinda like agree with you on the hard part defining a SC, but 1 4 1 is not the saviour here for people who need a clear dictinction to understand the / which component in error. Just like with focus. The errors group research clearly documented this based on user needs

[patrickhlauke]

sure, but i'd also say we need to be realistic - WCAG sets a baseline, and it makes not reaching the baseline effectively illegal (depending on context, legislation that just adopts WCAG by reference, etc). we'd need to be very sure that we have solid normative parameters, and that we're not overreaching in shackling designers/developers to necessarily only allow one particular style/presentation, i'd say...