Ensure form field constraints and errors are associated with their corresponding field

Media Type Web > Forms
State Active
Advisory No

When form fields have error messages or specific constraints, such as required state, formatting requirements, or unit requirements, developers must ensure these requirements are clearly communicated. These requirements should be communicated visually to the immediate left/above or right/below the field as well as programmatically associated with the field. Examples of form field constraints include:

Date Masks (i.e. YYYY/MM/DD)
Required field indicators
Text representing a minimum and maximum range of numbers

When field constraints are not displayed users with cognitive disabilities may not know what the minimum fields to complete are. When errors and constraints are not associated with a field users of assistive technology may not understand the relationship of the constraint to the field.

Compliant Example

<!-- Constraint text in the label as the accessible name for the input -->
<label for="date1">
  Date*:
  <input type="text" id="date1" name="date1"
required>
  Format: MM/DD/YY
</label>

<!-- Using aria-describedby to programmatically associate the error text with the input
-->
<label for="date2">
  Date*
  <input type="text" id="date2" name="date2"
aria-describedby="date2Error" required>
  Format: MM/DD/YY
</label>
<div id="date2Error">Error: Incorrect date format used.</div>

<!-- Using aria-describedby to associate the constraint text with input
programmatically -->
<label for="date3">Date*</label>
<input type="text" id="date3" name="date3"
aria-describedby="date3Format">
<span id="date3Format">Format: MM/DD/YY</span>

<!-- Using aria-required to set the required state for the input programmatically
-->
<label for="firstName1">First Name*</label>
<input type="text" id="firstName1" name="first_name1"
aria-required="true">

<!-- Using the HTML5 required attribute to set the required state for the input
programmatically -->
<label for="firstName2">First Name*</label>
<input type="text" id="firstName2" name="first_name2"
required>

Non-Compliant Example

<!-- Form field with constraints that are not associated with the field -->
</div>
  <label for="d1">Date: </label>
  <input id="d1" type="text" name="sample_field">*
  <span>MM/DD/YY</span>
</div>

<!-- Required field without associated required status -->
<span>*</span>
<label for="name">*Name: </label><input type="text" id=
"name" />.

<!-- Form field with errors that are not associated with the field -->
</div>
  <label for="d1" Date:
  <input id="d1" type="text" name="sample_field">*
  <span>MM/DD/YY</span> </label>
  <span id="error1"> Incorrect date format used</span>
</div>

Ensure that all label text, including field name, required state, associated error messages, and any required formatting information is provided. This is best done by enclosing this information in the label element. The label and constraints element should be located to the immediate left or right of the field as displayed on the screen. There are additional techniques that can be used to associate constraints with fields including the aria-required attribute, the HTML5 required attribute and other mechanisms to assign/associate an accessible name to a field such as aria-label and aria-labelledby. The aria-describedby attribute can also be used to associate form field instructions and constraints with a form field. Keep in mind that constraints including required or optional fields must be communicated both visually and programmatically.

"In some forms, it may be that all fields are required. Rather than indicating in every field that it is required, it may be simpler to meet this compliance requirement by placing simple text at the beginning of the form such as "All fields are required." Similarly, if most fields are required, the text atop the form could say "All fields are required except where indicatedâ€, with the optional fields visibly including "(optional)" in their labels. Note that while aria-required="true" indicates required fields to Assistive Technology, aria-required="false" is not a supported method of indicating optional fields."

A note about the HTML5 required attribute. This attribute when set indicates that a form field is required. This attribute may not be detected by all assistive technologies and also cannot be detected visually until the user submits the forms at which time browsers may highlight the field in a red color and when focused or hovered may display an error message. Thus, when required attribute is use on the form fields, additional mechanisms other than required attribute must be used to indicate the required fields. For example, providing a cue that an asterisk is a required field indicator and including the asterisk inside the explicit label of the form field is an optimal solution when required is used in the form fields. An explanation of what the asterisk indicates should be provided at the top of the form -- e.g. "Required fields are marked with an *".

Organization Standards

§ 508-1194.22 Web Sites and Applications
- (n) Ensure electronic forms are accessible
Section 508 and 255 (Revised 2017)
- Chapter 3: Functional Performance Criteria
  - 302.2 With Limited Vision
  - 302.1 Without Vision
  - 302.9 With Limited Language, Cognitive, and Learning Abilities
WCAG 2.0 Level A
- 1.3.1 Information and relationships conveyed through presentation
- 3.3.2 Labels or Instructions
- 4.1.2 Name, Role, Value
WCAG 2.1 Level A
- 1.3.1 Info and Relationships
- 3.3.2 Labels or Instructions
- 4.1.2 Name, Role, Value

Other Mapped Standards

§ 508-1194.21 Software Applications and Operating Systems
- (d) Information about a user interface element must be textually available
- (l) Ensure usability of electronic forms
§ 508-1194.22 VA Testing Checklist - Web Sites and Applications
- (n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form
  - (n.2) Are form fields explicitly labeled using unique and meaningful labels, title attributes, or other accessibility supported method (e.g. aria-labelledby) that provide important information (such as â€œRequiredâ€ when this information is not provided by another method e.g. the required or aria-required attribute) and the expected input format)?
§ 508-1194.31 Functional performance criteria
- (a) Ensure access for blind and visually impaired
- (b) Ensure access for low vision users
47 CFR 14. Advanced Communication Services
- 47 CFR 14.21 Performance Objectives
  - (b) Accessible
    - (b)(1) Input, control, and mechanical functions shall be locatable, identifiable, and operable
      - (b)(1)(i) Operable without vision
      - (b)(1)(x) Operable with limited cognitive skills
    - (b)(2) All information necessary to operate and use the product
      - (b)(2)(i) Availability of visual information
      - (b)(2)(ii) Availability of visual information for low vision users
BITV 2.0 (Priority I)
- 1.3.1 Informationen und Beziehungen
- 3.3.2 Beschriftungen
- 4.1.2 Name, Rolle, Wert
DHS - Section 508 Compliance Test Process for Application (v 4.0)
- 1.2 Labels for Assistive Technologies
  - 1.2.2. Web: Forms
    - 1.2.2 A. A Web form field has no markup to associate it to its complete instructions and cues
HHS HTML 508 Checklist (2019)
- Section J: Sites containing Forms
  - J3 Are form validation errors clear and accurately identified in text?
HHS HTML 508 Checklist (Pre 2019)
- HHS Web 508 Checklist (n)
  - (14.2) Are all cues for filling out the form available to users of assistive technology, e.g. mandatory fields, help boxes, error messages?
JIS X 8341-3: 2004 - Technical Standards Subpart 5
- 5.3 (b) Ensure form fields are operable and clearly labeled
KWCAG
- 3-3 - Ensure forms are accessible
  - 3-3-1 - Ensure use label on each element for form control
Telecommunications Act Accessibility Guidelines
- 1193.41 Input, control, and mechanical functions.
  - (a) Operable without vision. Provide at least one mode that does not require user vision.
  - (i) Operable with limited cognitive skills. Provide at least one mode that minimizes the cognitive, memory, language, and learning skills required of the user.
- 1193.43 Output, display, and control functions.
  - (a) Availability of visual information. Provide visual information through at least one mode in auditory form.
  - (b) Availability of visual information for low vision users. Provide visual information through at least one mode to users with visual acuity between 20/70 and 20/200 without relying on audio.
WCAG 1.0 Priority 2
- 12.4 Associate labels explicitly with their controls.
WCAG 2.0 Level A & AA Baseline
- 10. Forms
WCAG 2.1 Level A & AA Baseline
- 10. Forms
WCAG 2.2 Level A
- 1.3.1 Info and Relationships
- 3.3.2 Labels or Instructions
- 4.1.2 Name, Role, Value
WCAG 2.2 Level A & AA Baseline
- 10. Forms

Severity
7 (yellow)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
in range of 1 to 10
Noticeability
3 ()
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
in range of 1 to 10
Tractability
6 ()
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
in range of 1 to 10

Ensure form field constraints and errors are associated with their corresponding field

Compliant Example

Non-Compliant Example

Organization Standards

Other Mapped Standards

Severity

Noticeability

Tractability