Forms Tests

[kengdoj]

Example: A form field is meant to be for a date input (based on data validation and general context on the page) but has a visible label of "Form Field 1."

1. What is the test result for SC 3.3.2 Labels or Instructions?
2. What is the test result for SC 2.4.6 Headings and Labels?

(Please provide explanation of your results.)

[kengdoj]

While not part of Section 508 since it is WCAG 2.1, and this SC is for controls, Understanding 2.5.3 Label in Name, under Intent:

In order for the label text and accessible name to be matched, it is first necessary to determine which text on the screen should be considered a label for any given control. There are often multiple text strings in a user interface that may be relevant to a control. However, there are reasons why it is best to conservatively interpret the label as being only the text in close proximity.

Conventionally the label for user interface components is the adjacent text string. The typical positioning for left to right languages is:

• immediately to the left of comboboxes, dropdown lists, text inputs, and other widgets (or in the absence of left-side labels, immediately above and aligned with the left edge of each input)
• immediately to the right of checkboxes and radio buttons
• inside buttons and tabs or immediately below icons serving as buttons

The rationale for some of these conventions is explained in G162: Positioning labels to maximize predictability of relationships.

It is important to bias towards treating only the adjacent text as a label because liberal interpretations of what constitutes a text label can jeopardize the value of this Success Criterion (SC) by lessening predictability. Isolating the label to the single string in close proximity to the component makes it easier for developers, testers, and end users to identify the label targeted for evaluation in this SC. Predictable interpretation of labeling allows users of speech recognition technologies to interact with the element via its conventionally positioned label, and allows users of screen reading technologies to enjoy consistency between the nearby visible label and the announced name of the component.

[KMSOC]

Based on what I believe WCAG's intention is (despite contradictory content in each Understanding for 3.3.2 and 2.4.6), our baseline tests are accurate. Thus, in your example above, results would be:

What is the test result for [SC 3.3.2 Labels or Instructions]? Pass
What is the test result for [SC 2.4.6 Headings and Labels]? Fail

I think there is some opportunity to add clarification in the baseline to avoid confusion and explain our interpretation for users, especially given that folks may combine these in one test process for alignment. Under 3.3.2, I think we should extract the following text from the Understanding and place it directly in the baseline to strengthen why we interpreted 3.3.2 in this specific way: "While this Success Criterion requires that controls and inputs have labels or instructions, whether or not labels (if used) are sufficiently clear or descriptive is covered separately by 2.4.6: Headings and Labels."

We should suggest to W3C some modifications of Understanding to avoid confusion; I will post some ideas in another comment.

[KMSOC]

Suggested amendments to 3.3.2:

The intent of this Success Criterion is to have content authors present instructions or labels that identify the for controls in a form so that users know what input data is expected. In the case of radio buttons, checkboxes, comboboxes, or similar controls that provide users with options, each option must have a appropriate label so that users know what they are actually selecting. Instructions or labels may also specify data formats for data entry fields, especially if they are out of the customary formats or if there are specific rules for correct input. [Comment: propose striking this just to avoid confsuion] Content authors may also choose to make such instructions available to users only when the individual control has focus especially when instructions are long and verbose.

The intent of this Success Criterion is not to clutter the page with unnecessary information but to provide important cues and instructions that will benefit people with disabilities. Too much information or instruction can be just as harmful as too little. The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation.

This Success Criterion does not require that labels or instructions be descriptive, correctly marked up, identified, or associated with their respective controls - this aspect is covered separately by 1.3.1: Info and Relationships. It is possible for content to pass this Success Criterion (providing relevant labels and instructions) while failing Success Criterion 1.3.1 (if the labels or instructions aren't correctly marked up, identified, or associated).

Further, this Success Criterion does not take into consideration whether or not alternative methods of providing an accessible name or description for form controls and inputs has been used - this aspect is covered separately by 4.1.2: Name, Role and Value. It is possible for controls and inputs to have an appropriate accessible name or description (e.g. using aria-label="...") and therefore pass Success Criterion 4.1.2, but to still fail this Success Criterion (if the labels or instructions aren't presented to all users, not just those using assistive technologies).

This Success Criterion does not apply to links or other controls (such as an expand/collapse widget, or similar interactive components) that are not associated with data entry.

While this Success Criterion requires that controls and inputs have labels or instructions, whether or not labels (if used) are sufficiently clear or descriptive is covered separately by 2.4.6: Headings and Labels.

[KMSOC]

Additional suggestions:

Benefits
Providing labels and instructions (including examples of expected data formats) helps all users - but particularly those with cognitive, language, and learning disabilities - to enter information correctly.
Providing labels and instructions (including 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.

Examples
A field which requires the user to enter the two character abbreviation for a US state has a link next to it which will popup an alphabetized list of state names and the correct abbreviation.
A field for entering a date contains initial text which indicates the correct format for the "Date".
To enter their name, users are provided with two separate text fields. Rather than having a single label "Name" (which would appear to leave the second text field unlabelled), each field is given an explicit label - "Given Name" and "Family Name".
A U.S. phone number separates the area code, exchange, and number into three fields. Parentheses surround the area code field, and a dash separates the exchange and number fields. While the punctuation provides visual clues to those familiar with the U.S. telephone number format, the punctuation is not sufficient to label the fields. The single "Phone number" label also cannot label all three fields. To address this, the three fields are grouped in a fieldset with the legend "Phone number". Visual labels for the fields (beyond the punctuation) cannot be provided in the design, so invisible labels are provided with the "title" attribute to each of the three fields. The value of this attribute for the three fields are, respectively, "Area Code", "Exchange", and "Number".

[kengdoj]

adding @bruce-usab for his attention to Kristen's suggestions to improve Understanding 3.3.2

[kengdoj]

issue #488 opened