Visible Required label and 3.3.2: Labels or Instructions

[LaurenceRLewis]

Understanding Success Criterion 3.3.2: Labels or Instructions
https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html

Benefits - bullet point 2
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.

Is labelling only the optional fields rather than the required fields a fail of 3.3.2: Labels or Instructions? If so, does anyone have any user data to back this up.

I believe it is non-compliant, however, need to get information on why.

[JAWS-test]

Understanding Examples:

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

Thus, it is not a violation if only the optional fields are marked. However, it is more common to mark the required fields

[LaurenceRLewis]

Thanks @JAWS-test I missed that in the understanding doc.

[LaurenceRLewis]

@JAWS-test I can’t find that paragraph in the understanding document. Can you provide the link to it please.

[JAWS-test]

https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html#examples

[detlevhfischer]

The question has come up whether in situations where most fields are required and it therefore seems more straightforward to mark the few optional fields as optional, the required status of required fields would need to be conveyed programmatically via required, aria-required.

• Would it be sufficient to have no required or aria-required attributes on the fields but a hint at the start of the form like "all fields are required unless marked as optional"? (I guess so)
• Would it even be sufficient to have no hint and no markup, just an (optional) in the label of the few fields that are not required (leaving required fields empty would then bring up error messages)?

[patrickhlauke]

having the required state conveyed programmatically would be a 4.1.2 issue, rather than a 3.3.2 one

[mraccess77]

I believe visually we previously agreed something like the following:

• Situations where some fields are and are not required you need to indicate which ones are required or optional visually
• If you use an asterisk - you have to indicate what it means.
• If all fields are required then it's best to say that for larger forms but may not be needed.

[detlevhfischer]

having the required state conveyed programmatically would be a 4.1.2 issue, rather than a 3.3.2 one

@patrickhlauke Agree it's not 3.3.2 - but regardless whether it falls under 1.3.1 or 4.1.2, the question remains if the lack of any programmatic attribute or text hint would be considered a failure if all fields (bar the optional ones) are required (as is often the case, think only of login forms).

[patrickhlauke]

@detlevhfischer just saying that the programmatic aspect itself can be left out of the conversation here altogether, as it's a separate issue. 3.3.2 is, from my recollection, all about the labels/instructions available to everybody (so programmatic-only indications don't count as they're not available to non-AT users). helps to compartmentalise the discussion to just the visible text label/instruction part.

and my take is still if (i'm sure we discussed it somewhere before) if it's clear from context that fields are all required - e.g. login form with user/pass, it's clear that both are required as otherwise you couldn't log in, it's not a failure NOT to say on the field labels "(required)" or even on the form itself that "both username and password are required to log in". in those cases, that info is implicit and likely logical to all. in cases where context is NOT sufficient, agree that not indicating in text (either on label or form itself) that all fields are required, it's a failure of 3.3.2. and if the majority of fields are required, then makes more sense to indicate for the form itself "all fields are required unless marked as optional" or something, and then adding "(optional)". if the majority of fields are optional, and only a few are required, doing the opposite. and not doing so would, in my view, be a failure of 3.3.2

[mraccess77]

So to make sure we agree - for larger forms where it is not clear if things are required or optional - even if all are required there still needs to be instructions indicating that.

For small forms like search and login where fields are required - there is no need to mark them visually as required.

Sounds like Patrick and I are aligned.

[detlevhfischer]

Thanks @patrickhlauke and @mraccess77
I was tacking this on here because I was searching for old issues covering what ways are deemed sufficient to indicate required status (programmatically and/or in text). I take it all agree that visually, it would be fine to mark just optional fields if these are fewer. For forms somewhat more complex than login where input in most fields will be needed and the few that are optional are marked as such in the label, it feels a bit cumbersome to repeat a sentence like "All fields are required unless marked optional" before each form, especially in a multi-step process. My line would be that having "optional" in the label, where it is available visually AND programmatically, would by implication sufficiently mark the rest of fields as required, both visually and programmatically.
Do you agree?

[mraccess77]

If individual fields are marked with text communicating optional or required that would be fine in my opinion.

[patrickhlauke]

would by implication sufficiently mark the rest of fields as required, both visually and programmatically.

i disagree a bit with the "programmatically" word there (as the required fields would still need to be actually conveyed as required programmatically in the 4.1.2 sense), but i think you're not using it that way here. so in general, i think we're agreed (that the presence of "(optional)" on some labels implies that the others are required)

[detlevhfischer]

i disagree a bit with the "programmatically" word there (as the required fields would still need to be actually conveyed as required programmatically in the 4.1.2 sense),

My interpretation of "programmatically available" would be that when focussing a field, the status "required" or "optional" is available (e.g., spoken by the screen reader) by way of being inside a programmatically linked label. To me that seems to satisfy 4.1.2. I do not believe 4.1.2 mandates that required or aria-required be used.

[patrickhlauke]

well, it's arguable... form controls have an explicit "state" in the DOM/accessibility tree for when they're required or not. while having the accessible name include that as text will still lead to it being announced by AT, i wouldn't say that in that case it's "conveyed programmatically" in the same sense as the actual state being set correctly is

[detlevhfischer]

@alastc is it worth putting this into a survey for a WG decision? (I know it may not seem urgent, but there seems to be sufficient uncertainty around what is required to nail this?)

[mraccess77]

I agree that a label with required in it as text could be used instead of the required or aria-required.

[goetsu]

@detlevhfischer @patrickhlauke to be clear can you confirm working group position on these specific cases :

• If all fields are required (like a login / password field)
  -- without any visually information that all fields are mandatory
  -- and without any required or aria-required attributs on the fields
• If all fields are required (like a login / password field)
  -- without any visually information that all fields are mandatory
  -- and with a required or aria-required attributs on the fields

[patrickhlauke]

I'm sure there's no unanimous "working group position", so i'll just give you my personal pragmatic one: I'd say both these scenarios are fine, especially for very common forms like login/password forms. once you get into more esotheric forms, i'd probably (depending on the form) at least mention as best practice that the form should at least explain that all fields are required somehow, not sure if i'd go as far as hard-failing it though. in cases where there's a mix of required and optional fields though, i'd of course want to see some differentiation (be it using text "(required)" in the label for those required fields, or "(optional)" for the non-required ones, and yes ideally aria-required or required on the required ones, though if the label text/accessible name already includes that as text, i'd likely be ok with only that as well)

[goetsu]

@patrickhlauke thanks for your personal pragmatic opinion that I share ;)
I think that the understanding text of the SC or at least the text of the H90 technique will gain to be made more clear on such case with a note in the description for example like "When all fields inside a form a required event if it's a good pratice there is no formal requirement for them to have a visual indication that they are required before the user submit the form"

[bruce-usab]

@goetsu — I think it is fair to characterize similar WG discussions to focusing on the exact phrasing of the SC. So I agree with @patrickhlauke analysis.

With regard to suggestions for the Understanding, please be encouraged to submit a PR with your proposed edit, as that is concrete way to get feedback (pro or con). That said, historically it seems to me, there is a reluctance to have Understanding documents highlight minimally conforming examples which are not good patterns to model. From that perspective, the detail that there is no formal requirement is something I would suggest trying to soften. So perhaps:

Even when all fields inside a form are required, it is a good practice to have a visual indication that they are required before the user submits the form.

[goetsu]

thanks @bruce-usab my question was also to know where it's best to make the change in the understanding of the SC or in the description of H90 technique or both ?

[bruce-usab]

I suggest H90 over Understanding for 3.3.2. I see that I used Understanding too broadly with comment above. Thank you for your interest!

[goetsu]

done #2282

[rvantonisse]

Hello,

I am looking for a fixed answer for this particular, asterisk as required field indicator but not explained, case and what have been commented by @mraccess77 :

If you use an asterisk - you have to indicate what it means.

This asterisk (*) thing, that is being used often to indicate required fields, keeps popping up once a while. However, I dont seem to be able to find or save a clear resolution on this topic. A few days ago, discussion around the asterisk popped up again (WCAG-Audit-Discussions/NL-BE#40 - Dutch) and issuer also posted this in the A11y slack #wcag channel.

My opinion on this matter is that the asterisk is beeing used as non-text content, like a symbol of sorts. And therefore should have a text alternative as is required for success criterion 1.1.1 Non-text content. But what this question keeps unanswered are arguments like "It sucks for everyone, thus it is not an (WCAG) accessibility issue..." (this seems to me it is a 100% accessibility issue) or more literall "an asterisk is a text character so it does not need a text alternative" (the asterisk, text, is used as visual indicator, non-text content or at least not human language).

What I currently accept as text alternative for a required field indicated with an asterisk is either:

• The asterisk visually explained before (H90) or directly after the form
• The asterisk explained as error message after submission, either or both at the field or before/after the form as visual message. (This still is a UX issue but at least accessible)

Otherwise my resolution would be to fail this case under success criterion 1.1.1 non-text content.

This issue is also relevant and beeing referred to: #2357, I couldn't read a clear consensus there either.

I have looked at WCAG conformance, related success criteria (1.1.1, 3.3.2) and glossary normative sections a few times (and more). The technique H90 is the only place I could find that exactly shows an example (2) of how to use an asterisk for required field indication, but this is informative and missing reasoning for why:

It is important that the asterisk meaning is defined at the start of the form.

I am looking for a normative way of consensus, but I need help or direction to get there.

[scottaohara]

I also think some clarity is needed for this example - because I tend to disagree that it is always necessary to inform people that an very common visual marker - used quite consistently across the web - needs to be constantly prefaced with what it means. Particularly in regards to modern web apps where people are often needing to input interact with required fields across various pages/screens of the app. We don't require that people provide a legend for other common form icons, such as warning symbols for errors or checkmarks for valid input. Asterisks to indicate the required nature of a field is similar to those at this point.

Per the referenced example 2 - I would expect this to be qualified with "because the <input> in the following code snippet does not use the aria-required=true or required attribute, and instead relies solely upon the asterisk in the label to indicate that the field is required, the meaning of the asterisk needs to be provided".

However, if the form field were to use either aria-required=true or required, then I submit it is not necessary to tell people the meaning of the asterisk, as the form field itself will programmatically expose it is required, and the asterisk is now a visual representation of the field's programmatic required state.

[GreggVan]

I worry when we say that we don’t have to do something because it is common across the web and everybody knows about it. If you mean everybody who is already Web savvy — I agree. But there are many new comers (and even OLD newcomers) and using these conventions without explanation really falls into the category of jargon — and we speak specifically about not using jargon without explaining it. So no - I don’t think we should every assume that "people already know what that means" unless we don’t intend to include newcomers (and some people with cognitive, language, and learning disabilities.) NOW - how do we mark things up so that it will pop out to newcomers and others who need it — but not clutter up the page for everyone else. THAT is the question. Aria markup won’t solve that because newcomers (and others who need it) probably won’t know what that is or have tools that will show it. hmmmmm [edited to remove email cruft]

[patrickhlauke]

at what point do you make it mandatory though for all sites to be "newcomer friendly"? is that the purpose of WCAG? 3.3.2 is single A, so are you saying no site is ever allowed to use something like an asterisk without explaining what it means, or explicitly saying "(required)" even in obvious cases (like a login form with username/password ... it's self-evident that both are required, otherwise what kind of login form would it be)?

[GreggVan]

Asterisks are not a Web Thing They have been around for 50 years — but they are always accompanied by a footnote or legend that says what they mean. Note that I also said (and others) next to newcomers. There are disabilities that also will not know some of the things that the rest of us notice or know. You will also note that I didnt say that I had the answer. Just that I was not comfortable saying we should just accept things as ok just because those of us who are webbies know that it means best g [edited to remove email cruft]

[scottaohara]

@GreggVan well, i never said "everybody knows about it", so I just want to be absolutely clear on that, as you're responding to me as if I had.

I said:

I tend to disagree that it is always necessary to inform people that an very common visual marker - used quite consistently across the web - needs to be constantly prefaced with what it means.

emphasis on "always necessary" - which leaves room for situations where it may be necessary, but allows for people to not have to remind someone perpetually what a common visual indicator means when they will be encountering it several times.

[bruce-usab]

@rvantonisse

I am looking for a normative way of consensus, but I need help or direction to get there.

For normative look to exact phrasing of the SC. Do we have an SC that states required fields must be marked as being required? If not, the question is in the realm of best practices, and might documented in a Technique or Understanding document.

The other question to ask: Is this something which disproportionately impacts people with disabilities?

If so, then the something is a good candidate for the informative documents (if that something is not already a normative SC).

Assuming everyone knows * means required does impact PWD. It is worth mentioning as a best practice to have that explicitly, at least on longer forms. @patrickhlauke counterexample of ID/password exemplifies why asterisk on required fields is not universal, and it should not be.