Does 3.3.2 mandate forms that have required/optional fields indicate this visually?

[mraccess77]

If I have fields that are optional/required but this information is not communicated visually (either in at the form level or field level until the form is submitted -- is this a violation of SC 3.3.2?

This is a followup on Issue 121 (but not seeking a failure technique-- just a decision)
#121

<form>
<p>
<label for="name">Name</label>
<input type="text" id="name">
</p>
<p>
<label for="city">City</label>
<input type="text" id="city">
</p>
<p>
<label for="date">Date of birth</label>
<input type="text" id="date">
</p>
</form>

[JAWS-test]

I would say: Yes, required or optional fields must be visually marked according to SC 3.3.2. There is also a technique (H90) and an example in the Understanding for it:

In a form which contains both required and optional fields, the required fields and/or the optional fields are clearly labeled as such.

[patrickhlauke]

It will depend on context - on forms where it's clear that an input will be required, it's unnecessary (e.g. a search form with a single required text input and a search button, or a login form with only the required username and password fields). On mixed forms that have both required and optional fields, I would say yes it's a failure (unless the site does the opposite and marks optional fields as being "(optional)" or similar).

[WilcoFiers]

I think that depends on how liberal you want to be in your interpretation. Strictly speaking, the SC doesn't ask it, so it's not required. There are some indications that it's recommended, from the understanding docs and the SC, but those aren't normative, and understanding docs / sufficient techniques generally don't state the minimal requirement.

I can certainly see an argument for saying that required fields have to be indicated, but alternatively, an error message indicating that certain fields were required seems equally valid.

[patrickhlauke]

apologies, i was thinking stupidly about 2.4.6 Headings and Labels and the requirement to "describe", rather than 3.3.2 that just requires the presence of some form of label/instruction. but even under 2.4.6, it's difficult to define how far the "describing" aspect needs to go.

[awkawk]

According to the Understanding document, yes. In the 2008 version (and up to Feb 12, 2019) the understanding document included this specific benefit:

Clearly identifying required fields prevents a keyboard only user from submitting an incomplete form and having to navigate the redisplayed form to find the uncompleted field and provide the missing information.

In February of this year we discussed a few changes from @patrickhlauke:
https://www.w3.org/2019/02/12-ag-minutes.html#item10
Discussed direction in Issue #610

https://www.w3.org/2019/02/19-ag-minutes.html#item07
Discussed PR#612 (#612)

Now the Understanding document includes:
In benefits:

Providing clear and unambiguous labels and instructions (including clear identification of required fields) can prevent users from making incomplete or incorrect form submissions, which prevents users from having to navigate once more through a page/form in order to fix submission errors.

and
In examples:

In a form which contains both required and optional fields, the required fields and/or the optional fields are clearly labeled as such.

So, based on the original Understanding document and the current version, it seems that 3.3.2 does require that required fields with labels include information to indicate that they are required.

Presumably, since "labels or instructions" can be satisfied with just instructions, the instructions in that situation would also need to include information about which fields are required.

[JAWS-test]

but alternatively, an error message indicating that certain fields were required seems equally valid.

Guideline 3.3 is about "Help users avoid and correct mistakes."

SC 3.3.2 is responsible for avoidance. In my opinion it would be contrary to the spirit of the WCAG Guideline "3.3 Input Assistance" to display required fields only after sending the form via an error message.

[patrickhlauke]

So, based on the original Understanding document and the current version, it seems that 3.3.2 does require that required fields with labels include information to indicate that they are required.

If we want to be pedantic (which of course I love), the understanding documents are non-normative though. If the intent was to make this normatively required, then it should have been in the normative language...

(or even just some wording that specifies that the labels/instructions need to be sufficiently descriptive....which is still vague, but would mirror the vagueness of headings and labels' normative wording)

[patrickhlauke]

and i see that from my PR https://github.com/w3c/wcag/pull/612/files I actually make the point about cross-referencing headings and labels.

<p>While this Success Criterion requires that controls and inputs have labels, whether or not
        these labels are sufficiently clear or descriptive is covered separately by
       <a href="labels-or-instructions">2.4.6: Headings and Labels</a>.
</p> 

So, the intent/benefits really work hand in hand with 2.4.6. so, at a stretch, i'd still say not identifying required fields (in situations where it's ambiguous if a field is required or optional) falls under 2.4.6 (so pass/fail there). only if fields lack ANY labels/instructions do they fail 3.3.2

[awkawk]

@patrickhlauke Sure, the Understanding documents (and techniques) are non-normative, but they are the best indication of the Working Group's intent for the SC so are very useful for reducing subjectivity (note that I didn't say "eliminating subjectivity"), as I know you know.

I don't think that the intent of the WG was to lean on 2.4.6 to ensure that labels included information about whether a field is required or not. I do agree that the simple SC text of "Labels or instructions are provided when content requires user input" doesn't have the same level of specificity that would make it 100% clear that the WG was thinking about indicating which fields are required, so I'm relying on my memory from 2006-2008 a bit and much more on the Understanding document.

[patrickhlauke]

while true that non-normative documents help clarify what was intended...it's also true that what really counts is the normative wording. non-normative documents can help disambiguate, but aren't supposed to introduce new/stricter requirements.

this (going from "Labels or instructions are provided when content requires user input" to then saying that also always meant to say "and those labels/instructions need to be descriptive enough, e.g. required fields need to be identified as such") is going a bit too far in actually redefining what the SC text itself says, considering that there's not even a hint of this in the normative wording itself.

if it has always been the intention (implied) that labels/instructions should be descriptive, then that should have been either written as such normatively from the outset, or patched in an errata. though because 2.4.6 DOES actually say "Headings and labels describe topic or purpose" and here, "describe topic or purpose" CAN be interpreted as also including things like "and say if a field is required", i'm still leaning towards this interpretation. pass 3.3.2, fail 2.4.6 (in cases where it's ambiguous if a field is required or not).

completely incidentally...this could have made another good example for https://patrickhlauke.github.io/wcag-interpretation/

[mraccess77]

Thanks everyone. I wasn't clear in whether the "benefits" of a success criteria should be read as "sufficient techniques" vs. "failures" if you don't do them. It sounds like from this discussion one could read that the benefits and examples bend strongly toward what the working group interpreted the SC to require rather than just sufficient techniques (although I understand that these are just normative documents).

[patrickhlauke]

Did this reach some form of consensus? Can it be closed? It seems that based on changes I pushed on #612 - which adds

In a form which contains both required and optional fields, the required fields and/or the optional fields are clearly labeled as such.

as an example to the 3.3.2 understanding document https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html that there's a general feeling that yes, where it's really ambiguous if a field is or isn't required, that this can be noted as a failure of 3.3.2 (though it's still slightly "grey area" if this means that required fields must ALWAYS be clearly marked as such, as this can depend on context/the auditor's own subjective assessment of whether or not it's sufficiently clear from context if a field is required or not - e.g. in a login form, it's probably commonly understood that both username and password are required, and they don't need to be explicitly labelled as such).

long way of asking: can this issue be closed @mraccess77 ?

[scroniser]

Please consider the following situation:
When there is a mix of required and optional fields, the developers choose to mark required fields through the HTML attribute. The visual marker, on the other hand, is only on the optional fields. Under the current guidelines, they may argue that this is a sufficient technique.

It would be helpful to have some language (in this SC or elsewhere) that ensures that when parity is possible it is executed.

[patrickhlauke]

When there is a mix of required and optional fields, the developers choose to mark required fields through the HTML attribute. The visual marker, on the other hand, is only on the optional fields. Under the current guidelines, they may argue that this is a sufficient technique.

It would be helpful to have some language (in this SC or elsewhere) that ensures that when parity is possible it is executed.

isn't this parity? i mean from the end result's point of view, both AT users and non-AT sighted users can understand which fields are optional and which are required, no?

[scroniser]

@patrickhlauke - are you considering COGA?

[patrickhlauke]

what's your concern for COGA here, exactly? sighted users that also use AT and getting a potential mismatch (they hear required fields explicitly announced as required, but they see the optional fields visually identified as optional)? again, this seems to me that the end result is the same, the required and optional fields can be distinguished in both cases?

[mraccess77]

I want to clarify what the consensus is here - if the form only has required fields is it ok to not have a required field label or instructions? Is that the consensus?

[fstrr]

This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list.