Request for clarification: does Name, Role, Value include static states like "required"?

[brothercake]

The common understanding (or at least, mine and colleagues I've discussed this with) is that all states of an interactive control must be programmatically determinable, to conform with 4.1.2.

But I'm not entirely sure that the normative requirements actually say this:

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

The required state of a field is not its name or value, it isn't set by the user (until they submit and that fails validation, but that comes under 3.3.2), and notification doesn't apply because it's not changing dynamically (or maybe, it doesn't apply if it's not going to change dynamically).

4.1.2 doesn't seem to say that the required state (or other static author-set states) must be indicated at all. If it's visually indicated that the field is required but not programmatically indicated, then this comes under 1.3.1, however 1.3.1 is passed if the state is described in text (e.g., by saying "required" or that "* indicates a required field"). It seems like there's no failure anywhere for a required field to not programmatically declare that it's required.

Was that the intent, or have I misunderstood somewhere, or maybe the wording needs updating to match the apparently-common understanding (which is the most useful one after all)?

[detlevhfischer]

My take would be that as long as the required information is programmatically available in the context of the field (minimally even just through * in a correctly linked label) there would be no FAIL of 1.3.1 (and I think that the 4.1.2 text does not mandate the programmatic setting of the required state).

[cstrobbe]

States that can be set by the user include the focus state, the checked versus unchecked states, the selected versus non-selected states and the expanded versus collapsed states, but not "required", "disabled" or "hidden" (cf aria-hidden). Based on Understanding SC 4.1.2 for WCAG 2.0, I would say this distinction was intentional.

For the proper identification of required fields (including the asterisk mentioned in Detlev's comment), I would refer to SC 3.3.2 Labels or Instructions, which does not require programmatic determinability of this state.

I can't immediately think of a particular visual presentation for required fields that would not fail SC 1.3.3, SC 1.4.4 or both, and neither of these success criteria specifically require programmatic determinability.

[kaveinthran]

by having both programatic and visual indication, the accomodation is screenReader agnostic, I do think that the "required" state should be indicated programatically as it allows users to have a loewr cognitive load.
in my own experience as a long time web user, I get slightly anxious if the edit/form field have no optional/required lable, sometimes I am not interested to fill things that are optional.
I wish the communication can be more explicit, and do not rely on the user to make guesses.
currently, there's no failure anywhere for a required field to not programmatically declare that
it's required but I do think the notion of impairment/disability is evolving, therefore, it's important to have accomodation across the board.

In my situation, the * indication does not work for me as I use no punctuation with my screenreader and I guess there can be people that have same settings.
So, I do think, it's important to have programatic indication if there's wy for it.
Love to know your thoughts @stevefaulkner

[cstrobbe]

@kaveinthran For clarity's sake, the question raised here is not whether it is a good idea to mark the required "state" in a programmatically determinable way (e.g. by using the aria-required attribute), but whether success criterion 4.1.2 in particular requires this.

[WilcoFiers]

I tend to lean toward the philosophy of "if there were no semantics for it when we wrote the criterion, then it can't be required by them". So landmarks are not required, using role=menu / tablist / dialog is not, (aria-)required is not, etc. WCAG can't be a moving target. I.e. a page can't fail because it was built before we had these newer techniques for making things accessible. Unfortunately that means newer technologies aren't required until WCAG explicitly says they are, such as what WCAG 2.1 did for status messages.

[chaals]

Spoiler: IMHO you definitely need to include whether something is required under 3.3.2, and in general it should be there under 4.1.2 (the exception being if you aim to meet level A, actively try not to do anything better than that, and don't provide any visual indication at all that something is required).

My explanation:

@WilcoFiers suggested:

I tend to lean toward the philosophy of "if there were no semantics for it when we wrote the criterion, then it can't be required by them".

I don't believe that is the intention, nor that it was at the time.

But the specific question IMHO turns on whether being required is part of a role, or label. My reasoning is as follows:

"role" is defined in WCAG 2 as "text or number by which software can identify the function of a component within Web content". Not much help there - with the benefit of hindsight it seems like a really badly written definition for a term that was used with an undocumented understanding of something very heavily anchored in ARIA.

If there is a label, that clearly has to be represented. If part of the label is "*" which people are meant to intuitively know means "You have to fill in this field for the submission to be successful", that also has to be available.

3.3.2 does apply here. It doesn't require anything be programmatically identifiable, but it does require that users can find out about it. In the understanding document, which is about the strongest guidance available as to what the WG thinks it meant, there are clear examples of programmatic approaches, such as one for PDF forms or for Flash. And if you make it clear to someone that a form field is required, that becomes part of the labeling. QED.

[awkawk]

I would say that since the required state of a control is not user-settable, so isn't required under 4.1.2.

As Chaals says, if the required state is communicated by the label, then it would be expected to be communicated by the accessible name, which in the case of an asterisk (e.g., "phone number*") would be a 2.5.3 (Label in name) issue if the control had aria-label="phone number" without the asterisk.

If the required state is conveyed visually (e.g., thick dark border) then it would fall back to 1.3.1 (Information and Relationships).

@brothercake To your original question, I agree with you that not all states are required by 4.1.2 to be exposed programmatically, and yes, sometimes that means that the required state is conveyed in text content as allowed by 1.3.1.

[cstrobbe]

I tend to lean toward the philosophy of "if there were no semantics for it when we wrote the criterion, then it can't be required by them". So landmarks are not required, using role=menu / tablist / dialog is not, (aria-)required is not, etc.

How exactly does this work? When WCAG 2.0 was published in 2008, the first HTML 5 draft had not been published yet, so there was no role attribute in HTML or XHTML. (XHTML 1.1 got the "Role Attribute Module" in December 2020.) WAI-ARIA 1.0 didn't become a recommendation until 2014.

Does this mean that websites didn't need to use any WAI-ARIA until 2018, when WCAG 2.1 was published? And that they only needed it for conformance with new criteria introduced by WCAG 2.1 but not for the older ones? (WCAG 2.0 defined SC 4.1.2 Name, Role, Value when five and a half years before WAI-ARIA became a recommendation, so it seems that WCAG conformance was, at least to some extent, a moving target from the beginning.)

[ljoakley]

@brothercake I believe that you answered your own question by quoting 4.1.2, "For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies." The word "required" is a property of a field thus is covered by the wording in 4.1.2,

[bruce-usab]

@brothercake please (1) close this issue or (2) give your permission to convert this issue to a discussion or (3) propose the change you would like to see in Understanding SC 4.1.2.

[patrickhlauke]

From some informal discussion in today's WCAG 2.x backlog meeting, it does seem that this general area does bring up some diverging opinions, so worth discussing further.

[mbgower]

I missed the call, but I agree with a number of comments that a tight reading of 4.1.2 leads to a conclusion that it is not a failure of 4.1.2 to omit the use of aria-required where the information is provided in the UI. For example, the following passes 1.3.1 and doesn't fail 4.1.2: a legend reads "All fields are optional unless indicated" and "(required)" is included in the (properly constructed) labels of the inputs that are required.

[bruce-usab]

Discussed on call 3/29 as similar in nature to #3553 -- and in need of a proposed response.

[brothercake]

@bruce-usab Sorry I'm a bit slow to respond -- is there still something I need to do here?