Section 508 ICT Testing Baseline

10. Forms

Accessibility Requirements

• WCAG2 SC: 1.1.1. Non-Text – All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for [specific] situations:
  • Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)
• WCAG2 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
• WCAG 2.4.6 Headings and Labels: Headings and labels describe topic or purpose.
• WCAG 3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
• WCAG2 3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
• WCAG2 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input.
• WCAG2 3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.
• WCAG2 3.3.4 Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:
  1. Reversible: Submissions are reversible.
  2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
  3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
• WCAG2 4.1.2 Name, Role, Value: 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.

Test Method Rationale

Review form instructions for completeness and programmatic association to their inputs. Enter erroneous inputs and review error notifications provided to the user.

Limitations, Assumptions, or Exceptions

• Read-only (e.g. pre-filled) form fields receive keyboard focus and are selectable but cannot be modified. These must be labeled and programmatically determinable, and are tested under SC 1.3.1.
• Disabled input elements do not receive keyboard focus, cannot be selected, and cannot be modified. These are not included in this test.
• The combination of an element’s accessible name and accessible description is its text alternative.
• Clicking an option or selecting an option in a form should select the option, but should not initiate a change in context.
• Change of context is a major change that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously. Changes in context include changes of:
  1. User agent
  2. Viewport
  3. Focus
  4. Content that changes the meaning of the Web page
     • Note: A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).
     • Example: Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.
• Per WCAG 2.2 Understanding SC 3.3.2: Labels or Instructions, 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.

10.A Test Procedure for Form Names

Baseline Test ID: 10.A-FormName

Identify Content

1. Find all form components that do not have visibility:hidden or display:none. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
2. Find all instructions and cues (textual and graphical) that are related to form components, including groupings, order of completion, special conditions or qualifiers, format instructions, etc.

Test Instructions

1. Check that the combination of the accessible name and accessible description is not empty. [SC 4.1.2]
2. Check that the non-empty combination of the accessible name and accessible description describes the form's purpose. [SC 4.1.2] [Form components that include non-text content should also map to SC 1.1.1.] For details on the computation of the accessible name and accessible description, references include:
   • HTML Accessibility API Mappings 1.0 for text input
   • HTML Accessibility API Mappings for input controls
   • HTML Accessibility API Mappings for button element
   • HTML Accessibility API Mappings for input type="image"
   • HTML Accessibility API Mappings for Other Form Elements
3. Check that all relevant instructions and cues (textual and graphical) have programmatic association (e.g., table column and/or row header associations) to the form component. [SC 1.3.1]

Test Results

If any of the above checks fail, then Baseline Test 10.A-FormName fails.

10.B Test Procedure for Form Labels Descriptive

Baseline Test ID: 10.B-FormDescriptiveLabel

Identify Content

1. Find all form components that do not have visibility:hidden or display:none. Examples include buttons, text fields, radio buttons, checkboxes, multi-select lists.
2. Find all instructions and cues (textual and graphical) that are related to form components, including groupings, order of completion, special conditions or qualifiers, format instructions, etc.

Test Instructions

1. Check that provided labels (instructions and cues) for each form component describe purpose, inform users what input data is expected and, if applicable, what format is required. [SC 2.4.6]

Test Results

If any of the above checks fail, then Baseline Test 10.B-FormDescriptiveLabel fails.

10.C Test Procedure for On Input

Baseline Test ID: 10.C-OnInput

Identify Content

All active form components.

Test Instructions

1. Enter data in all form fields, and exit (tab out of) the field
2. Change selections and/or values for form components, such as radio buttons, check boxes, select lists, etc.
3. Check that navigating away from a component and/or changing component values/selections (e.g., entering data in a text field, changing a radio button selection) does NOT initiate a change of context unless the user has been advised of the behavior before using the component. [SC 3.2.2]
   Examples of a change of context could include:
   • Forms submitted automatically when exiting the field
   • Forms submitted automatically when exiting the last field in a form
   • New windows launched when changing a radio button selection
   • Focus is changed to another component when a select list item is selected

Test Results

If any of the above checks fail, then Baseline Test 10.C-OnInput fails.

10.D Test Procedure for Error Identification

Baseline Test ID: 10.D-ErrorIdentification

Identify Content

Input form components with automatic error detection and notification.

Test Instructions

1. Enter incorrect values in input form components in order to trigger automatic error detection that results in error notifications.
   Examples include but are not limited to:
   • required fields
   • date (format)
   • state (abbreviations in an address)
   • password
2. If an input error is automatically detected, check that the error notification meets all of the following [SC 3.3.1]:
   • the user is made aware of the error (whether immediately upon shifting focus away from the item in error or when trying to submit the form), and
   • the error is described to the user in text, and
   • the item that is in error is identified in text.

Test Results

If any of the above checks fail, then Baseline Test 10.D-ErrorIdentification fails.

10.E Test Procedure for Form has a Visible Label

Baseline Test ID: 10.E-FormHasLabel

Identify Content

1. Find all form components associated with data entry that do not have visibility:hidden or display:none. Examples include buttons, text fields, radio buttons, checkboxes, multi-select lists.
2. Find all instructions and cues (textual and graphical) that are related to the data entry form components, including groupings, order of completion, special conditions or qualifiers, format instructions, etc.

Test Instructions

1. Check that each form component has visible label(s) or instructions while the form component has focus. [SC 3.3.2]

Test Results

If any of the above checks fail, then Baseline Test 10.E-FormHasLabel fails.

10.F Test Procedure for Error Suggestion

Baseline Test ID: 10.F-ErrorSuggestion

Identify Content

Input form components with automatic error detection and notification.

Test Instructions

1. Enter incorrect values in input form components in order to trigger automatic error detection that result in error notifications. Examples include but are not limited to:
   • required fields
   • date (format)
   • state (abbreviations in an address)
   • password
2. Review error notifications provided.
3. Check that additional guidance (e.g., suggestion for corrected input, guidance on how to correct the user's input) is provided on how to correct errors for form fields that would not jeopardize the security or purpose of the content. [SC 3.3.3]

Test Results

If any of the above checks fail, then Baseline Test 10.F-ErrorSuggestion fails.

10.G Test Procedure for Error Prevention (Legal, Financial, Data)

Baseline Test ID: 10.G-ErrorPrevention

Identify Content

Page that causes legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses.

Test Instructions

1. Complete the form components necessary to submit. Include errors.
2. Check that at least one of the following is true [SC 3.3.4]:
   1. Reversible: Submissions are reversible.
   2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
   3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Test Results

If any of the above checks fail, then Baseline Test 10.G-ErrorPrevention fails.

Advisory: Tips for streamlined test processes

• For SC 3.3.1, acceptable techniques include (a) shifting focus to an error message informing the user that the previous field needs to be corrected and describing the error, (b) refreshing the page upon form submission, then listing the error descriptions and locations at the top of the page. Re-displaying the form and indicating the fields in error within the form is insufficient to meet this requirement. The user should not need to search through the form to find where errors were made.
• For SC 3.3.4, because the user can review a simple, 1-page form before pressing the submit button on the page, another review mechanism is not required.

WCAG 2.2 Techniques

The following sufficient techniques and/or common failures were considered when developing this test procedure for this baseline requirement:

• F36: Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value
• F37: Failure of Success Criterion 3.2.2 due to launching a new window without prior warning when the selection of a radio button, check box or select list is changed
• F82: Failure of Success Criterion 3.3.2 by visually formatting a set of phone number fields but not including a text label
• G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
• G80: Providing a submit button to initiate a change of context
• G83: Providing text descriptions to identify required fields that were not completed
• G85: Providing a text description when user input falls outside the required format or values
• G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text
• G131: Providing descriptive labels
• H44: Using label elements to associate text labels with form controls
• H65: Using the title attribute to identify form controls when the label element cannot be used
• H71: Providing a description for groups of form controls using fieldset and legend elements
• SCR19: Using an onchange event on a select element without causing a change of context