5. Forms

Applicability:

This Test Condition DOES NOT APPLY (DNA) if the page does not have form elements, if all form elements are disabled, or if no visual labels are provided for form elements.

How to Test:

1. Review the visual labels and/or instructions provided for each form component/control.
2. Determine whether labels and/or instructions for form components sufficiently describe the purpose and applicable data requirements (date formats, required fields, data type, etc.).

Evaluate Results:

If both of the following are TRUE, then the content PASSES:

1. Each visual form label is sufficiently clear and descriptive, so users know what input data is expected,
2. Each visual button label is sufficiently clear and descriptive, so users know its function.

Note:

• An error message is not sufficient to communicate the expected format to pass this test.
• The label or instruction can be graphical or textual.
• Any changes to form labels that occur automatically or as a result of interaction with the page should be included in this test.

Applicability:

This Test Condition DOES NOT APPLY (DNA) if the page does not have form elements.

How to Test:

1. Launch ANDI: focusable elements (this is the default selection).
2. Use the mouse or ANDI’s next/previous element buttons to highlight each focusable form element and review the ANDI output.
3. Review the ANDI Output for each focusable form field.
4. If the ANDI Output does not adequately define the form element, review other programmatic associations, such as table headings or location in a hierarchical list structure, to determine whether they provide or contribute to the form component’s description, cues, or instructions.
   • In cases where the purpose of the form element is intentionally vague or ambiguous (e.g., the content to be revealed after selecting a link to “Door 1,” “Door 2,” or “Door 3” is intended to be a surprise), it may be sufficient for the combination of form element text, accessible name, accessible description, and/or form element context to refer to its purpose vaguely or ambiguously

Evaluate Results:

If any of the following is TRUE, then the content PASSES:

1. The ANDI Output includes all relevant instructions and cues for the form element, including when fields are required, OR
2. Descriptive labels and cues are provided by other programmatic associations (e.g., table column and/or row associations), OR
3. A combination of ANDI Output AND other programmatic association includes all relevant instructions and cues, OR
4. The combination of the programmatically determined form element context and the ANDI Output provide adequate description of its purpose.

Note:

• This test also covers the requirement for WCAG SC 4.1.2 Name, Role, Value.
• Any changes to form elements that occur automatically or as a result of interaction with the page should be included in this test.
• To evaluate labels and cues provided by other programmatic associations, it may be necessary to perform other tests, including but not limited to 14. Tables and 10. Content Structure.
• At minimum, radio buttons and checkboxes should be programmatically associated with their question and response.
• Form fields are not required to have programmatic associations with form section headings unless there is significant risk of confusion.

Applicability:

This Test Condition DOES NOT APPLY (DNA) if the page does not have form elements.

How to Test:

1. Use the keyboard to navigate to form elements, e.g., text fields, radio buttons, checkboxes, buttons.
2. Complete the form element, e.g., select the radio button or check box, type information into the text box, select an item from the drop down.
3. Exit (tab away from) the completed form element and determine whether there are any instances of an unexpected change of context.
4. Changes in context include changes of: user agent, viewport, focus, content that changes the meaning of the page, e.g., a form automatically submitted when exiting a field, a new window launched when a radio button is selected.
   1. Note: A change is not considered unexpected if:
      1. The user is notified that a change of context is about to occur.
      2. The control is clearly intended to initiate a change in context when activated.

Evaluate Results:

If the following is TRUE, then the Test Condition is TRUE and the content PASSES:

1. Changing the value of a form element does not initiate an unexpected context change.

Note:

• For some types of form fields, such as text input fields, it may be necessary to move focus away from the field to trigger an input event.

Applicability:

This Test Condition DOES NOT APPLY (DNA) if the page does not have form elements or if the page content does not change due to form interaction.

How to Test:

1. Continue from Test 5.D.
2. If necessary, repeat the interactions that trigger changes to content of the page (instructions changed, error notification, content removed, content is added, button name, etc.).
3. Identify how the user is notified of the change in content.
   1. Determine whether the form element that triggers the change has an accessible name, accessible description and/or context that provides sufficient description of the interface component’s purpose.
      1. If content changes are the direct result of a user's action while interacting with content AND the interface component that triggers the change provides sufficient description of the change, then no additional programmatic event notification is necessary.
   2. Identify any dialogs that alert the user to changes in content.
      1. Determine whether the dialogs provide sufficient programmatic notification of content changes.
   3. Identify content changes that result in focus moving to the content that has changed.
      1. Determine whether moving the focus to the content that has changed is sufficient to notify the user of the change event (e.g., by describing the change directly in the content to which the focus moved).
   4. Identify content changes occurring in an ARIA Live Region:
      1. Launch ANDI: structures
      2. Click the “live regions” link, then use the mouse to hover over any identified live region (alternatively, use ANDI’s previous/next element buttons to navigate to identified Live Regions).
      3. Determine whether the changing content is contained within the Live Region.

Evaluate Results:

If any of the following is TRUE, then the Test Condition is TRUE and the content PASSES:

1. The user’s action directly results in the change in content, AND the interface component that triggered the change provided sufficient description about the change event
2. The page notifies the user about a change via a keyboard-accessible dialog
3. The page moves focus to the content that has changed, AND the content that has changed provides sufficient description about the change
4. The content that has changed is contained in an ARIA Live Region.

Note:

1. All form elements that changed during this test are to be tested per Test ID 5.C.
2. It may be necessary to use the mouse to determine whether state changes occur on hover or on click.
3. Depending on the component, a change of state may be triggered by various actions, such as changing values or states of other components, toggling a function, entering data in the component, mouseover, etc.
4. This list of techniques to meet SC 4.1.2 is not all-inclusive; there may be emerging techniques not explicitly spelled out that are acceptable.

Applicability:

This Test Condition DOES NOT APPLY (DNA) if the form element does not have automatic error detection.

How to Test:

1. Intentionally violate formatting and other form instructions, e.g., leave a required form field empty, use a different date format than is required, and/or create a password that does not meet the password strength requirements.
2. Attempt to submit the form and/or move to the next page.
3. Determine whether the error is identified and described in text.
   1. The form field with the error is identified in text, e.g., “Error: Password field.”
   2. Text describes the error, e.g., in a dialog message that states, “the Password you entered is incorrect.”

Evaluate Results:

If the following is TRUE, then the Test Condition is TRUE and the content PASSES:

1. The item that is in error is identified in text and sufficiently described to the user in text.

Note:

• The error message may be tested as part of 4.1.2-change-notify-forms (Test ID 5.E).

Applicability:

This Test Condition DOES NOT APPLY (DNA) if any of the following conditions apply to the form element:

• There is no automatic input error detection.
• Based on the type of input required, suggestions for correction cannot be provided because they are not knowable.
• Providing information about how to correct the error would jeopardize the security or purpose of the content, e.g., details about an incorrect password.

How to Test:

1. Continue from Test 5.F.
2. Determine whether guidance provides sufficient details for how to correct the error and/or offers suggestions of corrected input.

Evaluate Results:

If ANY of the following are TRUE, then the Test Condition is TRUE and the content PASSES:

1. Suggestions for corrected input are provided
2. The description contains adequate information for the user to know what is required to fix the error

Applicability:

This Test Condition DOES NOT APPLY (DNA) if the form is only on one page OR does not do any of the following upon submission:

• Cause legal or financial obligations.
• Modify or delete user-controlled data in data storage systems.
• Submit test responses.

How to Test:

Complete the required form fields with intentional errors and submit the content.

Evaluate Results:

If any of the following is TRUE, the content PASSES:

1. The user can reverse the submission
2. The user is presented with an option to review, confirm, and correct information before finalizing the submission
3. The page checks data for input errors and allows the user an opportunity to correct any errors.

Note:

• Because the user can review a one-page form before pressing the submit button on the page, another review mechanism is not required.
• Understanding 3.3.4 explains “user-controlled data” as follows: “such as their entire travel profile in a travel services web site. When referring to modification or deletion of 'user controllable' data, the intent is to prevent mass loss of data such as deleting a file or record. It is not the intent to require a confirmation for each save command or the simple creation or editing of documents, records, or other data.”