Clarification on 3.3.2: Labels or Instructions with regard to required fields and Sufficient Techniques

[joe-watkins]

Hi folks! Can the Working Group comment on the following scenario with regard to 3.3.2: Labels or Instructions and required fields in a web form?

Scenario: Imagine a web form where fields that own descriptive labels are required for entry but they are not marked visually nor programmatically as required. Upon submission of the form, error validation kicks in and text appears indicating the field/s is required. The form does not have any instructional indicating that there are required fields.

It's my understanding that to satisfy 3.3.2: Labels or Instructions you can use G131 Providing descriptive labels AND G83 Providing text descriptions to identify required fields that were not completed.

Is my interpretation correct that WCAG does not require authors to indicate that fields are required as part of the label or accessible description as long as the label is descriptive (G131) and error validation using text descriptions is present upon form submission (G83)?

ps. I know this isn't good UX or advised - just strictly parsing WCAG with respect to satisfying the Success Criterion.

[patrickhlauke]

some related discussion here #1698

[bruce-usab]

Hello Joe Watkins. Thank you for the question and your interest with promoting accessibility!

Is my interpretation correct that WCAG does not require authors to indicate that fields are required as part of the label or accessible description...

That is correct, since there is no SC which says that. In general, poor UX which effects everyone (and not only PWD), won't be reflected in the normative phrasing of Success Criteria. It is also the case that the AG WG is reluctant to includes examples in Understanding (et al.) that are just-barely-passing-but-terrible.

[JAWS-test]

Is my interpretation correct that WCAG does not require authors to indicate that fields are required as part of the label or accessible description as long as the label is descriptive (G131) and error validation using text descriptions is present upon form submission (G83)?

My understanding of WCAG is that this is not correct. Required fields must be marked (according to 3.3.2). Regardless, labels must be meaningful.

[patrickhlauke]

@JAWS-test it is contextual to an extent. If you have a login form where of course both username and password are required, do you fail a page if it doesn't explicitly say "Username (Required)" / "Password (Required)"?

[bruce-usab]

3.2.2 reads:

Labels or instructions are provided when content requires user input.

Nothing in the above about the field being required or not. The base requirement, the SC text, is very minimal. It applies when there is user input.

[patrickhlauke]

it's the unfortunate use of "requires" in that wording, when really it's more about "accepts", "expects", "allows" (not the "required" in the sense that it is a "required field" in the validation sense)

[awkawk]

@JAWS-test I don't agree. If I have a form which provides no visible indication and no programmatic indication that five of the five fields are required, when I submit the form without completing two fields, I'll get a notification that I'm missing some information that is required. Lousy UI, but not a failure.

[mbgower]

Is my interpretation correct that WCAG does not require authors to indicate that fields are required as part of the label or accessible description...

That is correct, since there is no SC which says that.

I think that is debatable. There is no Failure technique that specifically calls that out -- which is the ultimate way of proving that something is a failure; however, there are a few techniques (sufficient and failure) that directly call out use of required, from which we can make a case:

• Indicating required form controls using label or legend
• Failure of Success Criterion 1.4.1 due to identifying required or error fields using color differences only
• Identifying a required field with the aria-required property

I find it most useful to look at the tests for these techniques

1. For each required form control, check that the required status is indicated in the form control's label or legend.
2. For each indicator of required status that is not provided in text, check that the meaning of the indicator is explained before the form control that uses it.

1. Check that an non-color way to identify the required field or error field is provided.

1. Check whether the aria-required attribute is present:
2. Check whether the value of the aria-required attribute is the correct required state of the user interface component.

I think it becomes pretty clear from looking at those Understanding documents and the tests in particular, that required fields form part of the labels or instructions for a form, and that visual information about this relationship must be programmatically determinable. So there are a few different SCs which can be brought into play to make a case.

The ARIA technique I cited does this. Note that they do have it as "advisory" for 1.3.1, not sufficient.

The objective of this technique is to provide programmatic indication that a form field (which shown through presentation to be required) is mandatory for successful submission of a form.

The fact that the element is required is often visually presented (via a text or non-text symbol, or text indicating input is required or color / styling) but this is not programmatically determinable as part of the field's name.

So, I think there could definitely be cases where I might try to make a case that something is failing one of those 2 SCs (for example, they put the asterisk outside the label programmatically, but it is there visually, so the AT never hears it announced while working in forms mode) and some where I'd think it doesn't.

Note also that the unfortunate use of the word "required" in the normative text of Labels or Instructions makes this even harder to tell, since you have to go back and consider the intent of the crafters of the SC about what the heck they meant when they used that word!

Success Criterion 3.3.2 Labels or Instructions (Level A): Labels or instructions are provided when content requires user input.

Getting back to the original question, the 2 general techniques combined are actually listed as sufficient for Labels or Instructions, but I think you're skating on thin ice with Info and Relationships on most forms (which usually have some visual indicator of required fields). You meet it in your scenario, though.

This technique relates to:

• Success Criterion 3.3.1: Error Identification (Sufficient)
• Success Criterion 3.3.2: Labels or Instructions (Sufficient when used with G131: Providing descriptive labels)
• Success Criterion 3.3.3: Error Suggestion (Sufficient)
• Success Criterion 4.1.3: Status Messages (Sufficient when used with ARIA19: Using ARIA role=alert or Live Regions to Identify Errors)

[awkawk]

@mbgower Techniques are not tightly scoped to only include what the required by the SC. For H90, yes, you can meet 3.3.2 by including information about whether the fields are required in the label or legend, but that is greater than the minimum requirement for 3.3.2.

For the 1.4.1 technique, it is required to indicate the required fields because it is shown in another way (color), and for ARIA2 again the presentation shows that the field is required so you need to match that for other users.

[mbgower]

Right, and my long-winded explanation gets to that. The only reason 1.3.1 doesn't factor in in this scenario is because the issue commenter says:

Imagine a web form where fields that own descriptive labels are required for entry but they are not marked visually nor programmatically as required.

So everyone gets the same crappy experience.

[awkawk]

"So everyone gets the same crappy experience." is about the same as my "Lousy UI, but not a failure" :)

[JAWS-test]

Lousy UI, but not a failure.

I don't see it that way. A bad UI means a significant extra effort for disabled people. Otherwise, there would be no need for the criteria in chapter 3.3. All SC in 3.3 are about avoiding bad UI: "Help users avoid and correct mistakes."

In the Understanding we can read:

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 a form which contains both required and optional fields, the required fields and/or the optional fields are clearly labeled as such.

Of course I agree with @patrickhlauke that there are cases where it is obvious from the context that all fields are required or optional

• Login: all required
• Survey at the bottom of the page "Did you find the information on the page helpful?": all optional

In most cases, however, it is not clear what are required fields, so my understanding is that they must always be marked

[JAWS-test]

In the established WCAG test procedures, 3.3.2 also explicitly checks for the marking of required fields, e.g. https://webtest.bitv-test.de/index.php?a=di&iid=291&s=n.

Are required fields in label or legend elements clearly displayed? If symbols such as an asterisk (*) are used for display, their meaning should be explained at the beginning of the form.

[bruce-usab]

@JAWS-test nothing wrong with test procedures and auditors going above and beyond the bare-bones minimum of the literal SC text. Ping to my colleague @kengdoj who might say if TT or baseline has a similar test step.

From the .de TLD could it be the case that your reference is a translation error? As @patrickhlauke notes above, it is problematic that requires user input is so easily conflated with required field. It is an easy mistake to infer, especially from a well-intentioned UX perspective.

[JAWS-test]

@bruce-usab Whether it is a translation error, @detlevhfischer can answer. But I do not believe that it is one

[detlevhfischer]

@JAWS-test BITV-Test does not generally mandate that required fields are marked (note the use of 'should'). We are also becoming less strict in mandating an explanation of asterisk at the start of the form if used to mark fields visually as required - see BIK-BITV/BIK-Web-Test#263
The argument from a 1.3.1 perspective we basically take into consideration in the evaluation of 3.3.1 is that if there is an indication of 'required' visually, it should be available programmatically in some way, and vice versa.
So if there is no marking of required (neither programmatically nor visually) and it is the error handling only that flags that fields were indeed required, this would be no reason for us to fail 3.3.2 - crappy UI for all.

[bruce-usab]

I would also note that this field is required might only follow from some analysis. For example, phone type (mobile/landline/fax) becomes mandatory iff a phone number is entered. If it is not always feasible for mandatory fields to be indicated then it cannot be the case that 3.3.2 says to always do that.

[cscheffauer]

@bruce-usab
not sure if this is the right thread to ask for guidance:
What about cases where a input field is used in a particular context, which might not be a form?
For example the WYSIWYG Text Editor in Chat / Messenger applications? It is technically a input, putting a visible label on the page is required by this SC - in a lot of cases it is weird in terms of UI / UX (the context of the messenger makes it clear that the input is for writing a message to someone).
Any guidance on this?

[bruce-usab]

@cscheffauer -- since 3.3.2 reads "labels or instructions" -- the verbatim wording allows flexibility. 3.3.2 does not dictate that you add a visible label where it would be superfluous (or confusing) for everyone (including users of assistive technology),

In general, if a developer feels forced to do something weird in terms of the common/usual UI/UX -- because of how they are reading a particular SC -- my experience is that the developer is reading something into the SC that is not literally there.

You note that the context is a non-web application, and that usually means there are platform-specific resources and conventions. Nowadays, it is not uncommon for platforms to be widely regarded as being accessible, and that the platform owner has developer-oriented documentation on accessibility APIs and features.