| redirect_to |
|---|
- 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:
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- 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.
Review form instructions for completeness and programmatic association to their inputs. Enter erroneous inputs and review error notifications provided to the user.
- 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 defined in Understanding SC 3.2.1: On Focus as: major changes in the content of the Web page 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:
- User agent
- Viewport
- Focus
- 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.
Baseline Test ID: 10.1-FormName
- Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, read-only fields, and multi-select lists.
- 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.
- Check that the combination of the accessible name and accessible description is not empty. [SC 4.1.2]
- Check that the non-empty combination of the accessible name and accessible description and other programmatic associations (e.g., table column and/or row associations) describes each form component and includes all relevant instructions and cues (textual and graphical). [SC 1.3.1] For details on the computation of the accessible name and accessible description, references include:
If any of the above checks fail, then Baseline Test 10.1-FormName fails.
Baseline Test ID: 10.2-FormDescriptiveLabel
- Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, multi-select lists.
- 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.
- 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]
If any of the above checks fail, then Baseline Test 10.2-FormDescriptiveLabel fails.
Baseline Test ID: 10.3-OnInput
All active form components.
- Enter data in all form fields, and exit (tab out of) the field
- Change selections and/or values for form components, such as radio buttons, check boxes, select lists, etc.
- 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
If any of the above checks fail, then Baseline Test 10.3-OnInput fails.
Baseline Test ID: 10.4-ErrorIdentification
Input form components with automatic error detection and notification.
- 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
- 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.
If any of the above checks fail, then Baseline Test 10.4-ErrorIdentification fails.
Baseline Test ID: 10.5-FormHasLabel
- Find all form components. Examples include buttons, text fields, radio buttons, checkboxes, multi-select lists.
- 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.
- Check that each form component has label(s) or instructions. [SC 3.3.2]
If any of the above checks fail, then Baseline Test 10.5-FormHasLabel fails.
Baseline Test ID: 10.6-ErrorSuggestion
Input form components with automatic error detection and notification.
- 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
- Review error notifications provided.
- 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]
If any of the above checks fail, then Baseline Test 10.6-ErrorSuggestion fails.
Baseline Test ID: 10.7-ErrorPrevention
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.
- Complete the form components necessary to submit. Include errors.
- Check that at least one of the following is true [SC 3.3.4]:
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
If any of the above checks fail, then Baseline Test 10.7-ErrorPrevention fails.
Form components that change are tested in [Baseline 5. Changing Content](05Changing.md).
- 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.
The following sufficient techniques and/or common failures were considered when developing this test procedure for this baseline requirement:
- G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text
- G80: Providing a submit button to initiate a change of context
- G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
- G131: Providing descriptive labels
- H44: Using label elements to associate text labels with form controls
- H71: Providing a description for groups of form controls using fieldset and legend elements
- H65: Using the title attribute to identify form controls when the label element cannot be used
- SCR19: Using an onchange event on a select element without causing 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
- 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