- All form fields require a label tag
- The Label tag explicitly associates a form field with a label
- When the text field or text field receives keyboard focus or a user clicks into the field, visible focus must be present. Examples of how to implement include:
- When text fields receive focus, a vertical bar is displayed in the field, indicating that the user can insert text, OR all of the text is highlighted, indicating that the user can type over the text (if placeholder text exists)
- When the field receives focus, a visible border is displayed around it.
Required form fields can be indicated in a variety of ways, but the method used must be perceivable with different senses so can’t rely solely on a difference in color, size or position of those fields. Keep in mind that visual and verbal instructions must be provided.
Ways to indicate a required text field:
- At the beginning of the form, clearly state that some form fields are required, and provide a key to how the required fields will be indicated
- Identify the required field with words or a symbol that can be programmatically associated with the field. This will usually mean the required field indication is contained within the label element.
How to visually indicate a required form field:
- Using the word “Required”
- Using an inline image (often a graphic star) with an appropriate alt attribute (e.g. “mandatory form field” or “required information”).
- Using the keyboard star (asterisk) symbol
How to verbally indicate a required form field (this is not an exhaustive list):
- Using the word “Required” as part of the <label for> tag
- Using “required” as part of the HTML 5 code
- Using aria-required=true
Required field Code Examples:
<label for=”email”>Email Address (required)</label>
<input type=”text” name=”email” id=”email”>
<label for=”email”>Email Address</label>
<input type=”text” name=”email” id=”email” required>
<label for=”email”>Email Address</label>
<input type=”text” name=”email” id=”email” aria-required=“true“>
- Help the user avoid input errors by informing them ahead of time about restrictions on the format of data that they must enter.
- If input field requires a specific format (e.g. a phone number or date), verbal and visual instructions must be provided communicating the required format.
- If there is a required character limitation on a text box, then that needs to be visually and verbally communicated. There must also be a verbal indication when the character count limitation has been reached.
- Placeholder text cannot be used a replacement for a form input label.
- The placeholder should be used like a title attribute (tooltip); and only provide supplementary information. Please refer to these articles to understand why placeholder text alone w/o a visible label presents an accessibility challenge:
- Form error messages should identify fields with errors and the nature of the error.
- Error messages must be presented in a format that is detectable by a screen reader.
- Color cannot be the only method used to identify the erroneous field (e.g. you cannot simply highlight the input field in red to indicate an error)
- When focus lands on the text field or text box, there should be no change of context.
- When a user types content in the field or tabs out of the text field, this should not trigger a change of context. https://www.wuhcag.com/on-input/
WCAG Specific Success Criterion to Consider:
- 3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A) – http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html
- 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. (Level A) – http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-identified.html
- 4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A) – http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html
- 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. (Level A) – http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html
- 2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A) – http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-receive-focus.html
- 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. (Level A) http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html
- 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA) – http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html