Does Info and Relationships require input fields to be surfaced programmatically when the accessible name does not make it clear that they are required?

[EmptyEnd6893]

I have noticed that the understanding page for Label in Name seems to suggest that Info and Relationships calls for required fields to be represented programmatically (at least when the accessible name does not make it clear that the field is required), by using techniques like the 'required' or 'aria-required' attributes. Here is how it is written on the page:

However, where parenthetical information provides important context, such as indication of a required field or limitations on what is allowed for input, this information must be provided programmatically in some other way to the user if that information is not included as part of the accessible name. For example, "Name (required)" and "Date (YYYY-MM-DD)" could accept "Name" and "Date" as the accessible names. However, in order to pass 1.3.1 Info and Relationships, authors would need to programmatically surface both the required state and the limit on the allowed data formatting (in this example, eight integers fitting the YYYY-MM-DD pattern). The "required" state could be surfaced through the HTML required attribute or by using aria-required="true".

I also noticed that the understanding page for Info and Relationships lists the following example:

A form contains several required fields. The labels for the required fields are displayed in red. In addition, at the end of each label is an asterisk character, *. The instructions for completing the form indicate that "all required fields are displayed in red and marked with an asterisk *", followed by an example.

Info and Relationships requires that Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. It seems like the example on the Info and Relationships understanding page presents the information as text associated using an asterisk character in the field label but does not mention that the required state should be programmatically determinable. The example also does not appear to suggest that the required state is clear from the accessible names of the input field. The example listed on the Label in Name understanding page seems to suggest that including the text '(required)' in the label (but not the accessible name) is not sufficient to pass Info and Relationships on its own. Could someone please clarify this for me?

[JAWS-test]

The two passages do not contradict each other. According to WCAG SC 1.3.1, the required information must either be part of the Accessible Name (e.g. as an asterisk) or be transmitted programmatically (e.g. via required).

If I do both (asterisk in the name and required attribute), this is not good because I can then perceive the information twice, e.g. with the screen reader, and therefore not efficiently.

If I do neither (e.g. asterisk only visually on the page, but not via label element as part of the Accessible Name; no required attribute), this is a mistake because I can then perceive the asterisk with the screen reader when reading the content, for example, but not when I navigate directly to the field with the TAB key.

[JAWS-test]

Important: In most cases, it is better to convey information programmatically than in text form. According to WCAG SC 1.3.1, transmission in text form is reserved for cases in which there is no possibility of transmitting the information programmatically. In my opinion, this is different for information on required fields, because the asterisk as part of the visual labeling and the Accessible Name is a very established pattern and therefore not necessarily worse than the required attribute. However, this can change if an assistive technology offers a function to highlight all required fields or to navigate specifically to them. Then the required attribute would be significantly better.

[patrickhlauke]

According to WCAG SC 1.3.1, transmission in text form is reserved for cases in which there is no possibility of transmitting the information programmatically.

not as cut and dry ... "when technologies support programmatic relationships, it is strongly encouraged that information and relationships be programmatically determined rather than described in text" - strongly encouraged, not "reserved for cases..."

[EmptyEnd6893]

Thanks for your reply. I was thinking something similar, although the example on the Info and Relationships page suggests that the label contains the asterisk but the name is not specifically stated as containing the asterisk. I suppose we can assume that the name contains the asterisk as well, as it is generally advised that form fields are associated using a 'for' attribute. If we can't assume that, I interpret the the Label in Name page as saying that adding (required) to the end of the label, but not the name, requires the field to be programmatically required. Would it be reasonable to apply this to an asterisk that is not neccessarily parenthetical?

[JAWS-test]

@EmptyEnd6893: You are right, in the first example there is no clear indication that the visual label must also be the programmatic name, including the asterisk. In the second example, however, it is explicitly stated:

Both the red text and the icon are programmatically associated with the appropriate form fields so that assistive technology users can determine the required fields. (https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html)

[EmptyEnd6893]

I did notice that the second example does explicitly state that they are programmatically associated so perhaps we can infer that the asterisk is contained in the accessible name of the first example. It just feels a little confusing to me why the Label in Name page seems to clarify this particular issue more than the understanding page for Info and Relationships. If I were to read the Info and Relationships page only, I would likely understand the issue differently.