Caution
This document is an English translation of the “freee Accessibility Guidelines.” The normative version of this document is in Japanese, and the English version is informational. The English translation is incomplete, and any links with their link texts left in Japanese are untranslated. Please be aware that there may be inaccuracies in the translation or parts that are outdated.
Forms
These guidelines cover general input forms as well as content that uses form controls such as input elements, even if it doesn’t look like a form at first glance.
Use Displayed Text as Label
Explicitly associate displayed text with form controls as labels.
- Target Platforms
Web, Mobile
- Intent
Enable individuals with visual impairments to easily determine the purpose of form controls.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 1.1.1 (Level A): Non-text Content
Success Criterion 1.3.1 (Level A): Info and Relationships
Success Criterion 2.4.6 (Level AA): Headings and Labels
Success Criterion 2.5.3 (Level A): Label in Name
Success Criterion 3.3.2 (Level A): Labels or Instructions
- Supplementary Information
Checklist Items
Check ID: 0931
In order to make the roles of form controls, such as edit boxes, checkboxes, and radio buttons understandable, design documentation explicitly specifies the labels to be added.
- For the web:
Specify text displayed on the screen or images with alternative text as labels.
Explicitly specify the text that should be designated as the
aria-labelattribute value.
- Applicable Stages
Design
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Check ID: 0941
Form controls such as edit boxes, check boxes, and radio buttons have labels that indicate their purposes.
- Applicable Stages
Code
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Implementation Example: Labeling Form Controls
- Web
Associate the displayed text or image with the
labelelement or thearia-labelledbyattribute, orSpecify the label with the
aria-labelattribute.
- iOS
Use
accessibilityLabel.
- Android
Use
labelFor.
Implementation Example: Checking for Appropriate States
- Web
When checked with developer tools, the accessible name of the form control specifies text that indicates its purpose.
Check ID: 0951
Form controls, such as edit boxes, check boxes, and radio buttons, are properly labeled.
- Applicable Stages
Product
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Check Procedure: Web
Confirm 0951-axe-01 passes, and (0951-nvda-01 or 0951-macvo-01 passes) below.
0951-axe-01: An Example of Performin the Check with axe DevTools
Confirm that none of the following issues are reported by axe DevTools.
0951-nvda-01: An Example of Performin the Check with NVDA
Confirm that the appropriate text, corresponding to the form control is announced when moving focus to the form control using Tab / Shift + Tab keys in NVDA’s focus mode.
0951-macvo-01: An Example of Performin the Check with macOS VoiceOver
Confirm that the appropriate text, corresponding to the form control is announced when moving focus to the form control using Tab / Shift + Tab keys with VoiceOver enabled.
When Displayed Text Cannot Be Used as a Label
If the displayed text cannot be used as a label for a form control, use hidden text to label it.
- Target Platforms
Web, Mobile
- Intent
Enable individuals with visual impairments to easily determine the purpose of form controls.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 1.1.1 (Level A): Non-text Content
Success Criterion 1.3.1 (Level A): Info and Relationships
Success Criterion 2.4.6 (Level AA): Headings and Labels
Success Criterion 3.3.2 (Level A): Labels or Instructions
- Supplementary Information
Checklist Items
Check ID: 0931
In order to make the roles of form controls, such as edit boxes, checkboxes, and radio buttons understandable, design documentation explicitly specifies the labels to be added.
- For the web:
Specify text displayed on the screen or images with alternative text as labels.
Explicitly specify the text that should be designated as the
aria-labelattribute value.
- Applicable Stages
Design
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Check ID: 0941
Form controls such as edit boxes, check boxes, and radio buttons have labels that indicate their purposes.
- Applicable Stages
Code
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Implementation Example: Labeling Form Controls
- Web
Associate the displayed text or image with the
labelelement or thearia-labelledbyattribute, orSpecify the label with the
aria-labelattribute.
- iOS
Use
accessibilityLabel.
- Android
Use
labelFor.
Implementation Example: Checking for Appropriate States
- Web
When checked with developer tools, the accessible name of the form control specifies text that indicates its purpose.
Check ID: 0951
Form controls, such as edit boxes, check boxes, and radio buttons, are properly labeled.
- Applicable Stages
Product
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Check Procedure: Web
Confirm 0951-axe-01 passes, and (0951-nvda-01 or 0951-macvo-01 passes) below.
0951-axe-01: An Example of Performin the Check with axe DevTools
Confirm that none of the following issues are reported by axe DevTools.
0951-nvda-01: An Example of Performin the Check with NVDA
Confirm that the appropriate text, corresponding to the form control is announced when moving focus to the form control using Tab / Shift + Tab keys in NVDA’s focus mode.
0951-macvo-01: An Example of Performin the Check with macOS VoiceOver
Confirm that the appropriate text, corresponding to the form control is announced when moving focus to the form control using Tab / Shift + Tab keys with VoiceOver enabled.
Expression Using Multiple Visual Elements
When indicating required fields or displaying errors, use visual elements in addition to color.
- Target Platforms
Web, Mobile
- Intent
Ensure that people with visual impairments or color vision deficiencies can use the content.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 1.3.3 (Level A): Sensory Characteristics
Success Criterion 1.4.1 (Level A): Use of Color
- Supplementary Information
- Related FAQs
Checklist Items
Check ID: 0031
The color scheme is designed to not hinder usability even in grayscale display:
Links can be distinguished
The intent of images and text is conveyed
Required items and errors in input forms can be recognized
- Applicable Stages
Design
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Check ID: 0051
The content is usable when displayed in grayscale, meeting the following:
Links can be identified
The intent of images and text is clear
Required fields and errors in ininput forms can be recognized
- Applicable Stages
Product
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Time Limit for Form Input
Do not set time limits for form input and operation. If time limits are set, at least one of the following conditions must be met:
Disabling: Users can disable the time limit before using a form with a time limit. Or,
Adjustment: Users can significantly adjust the time limit to exceed at least ten times the default setting before using a form with a time limit. Or,
Extension: Warn users before time expires, and allow them to extend the time limit by at least 20 seconds with a simple action, such as pressing the space key, at least ten times. Or,
Real-time Exception: The time limit is an essential part of a real-time event (e.g., an auction) where no alternative to the time limit exists. Or,
Essential Exception: The time limit is essential and extending it would invalidate the form. Or,
20-hour Exception: The time limit is longer than 20 hours.
- Target Platforms
Web, Mobile
- Intent
Ensure that forms can be used without issue even when it takes time to read or understand the content, or when input operations take time.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.2.1 (Level A): Timing Adjustable
Success Criterion 2.2.3 (Level AAA): No Timing
- Supplementary Information
Checklist Items
Check ID: 0961
Form inputs are not subject to time limits. Or, they meet one of the following conditions:
Users can disable the time limit in advance. Or,
Users can make a significant adjustment to the time limit, exceeding at least ten times the default setting, in advance. Or,
Users are warned before time expires and can extend the time limit by at least 20 seconds with a simple action, such as pressing the space bar, at least ten times. Or,
The time limit is an essential element of a real-time event (e.g., an auction) and there is no alternative to the time limit. Or,
The time limit is essential and extending it would invalidate the form. Or,
The time limit is longer than 20 hours.
- Applicable Stages
Design
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Continuing Operation After Exceeding Time Limit
Ensure that users can continue their operation without losing data even after exceeding the time limit.
- Target Platforms
Web, Mobile
- Intent
Ensure that forms can be used without issue even when it takes time to read or understand the content, or when input operations take time.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.2.5 (Level AAA): Re-authenticating
- Supplementary Information
Checklist Items
Check ID: 1021
If the time limit is exceeded while entering information into a form with a set time limit, it is possible to resume input without losing the content entered up to that point.
- Applicable Stages
Design
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Enable Keyboard Operation
Enable keyboard operation for all form controls.
- Target Platforms
Web
- Intent
Enable individuals with visual impairments or motor disabilities who do not use or cannot use a mouse to operate forms.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.1.1 (Level A): Keyboard
Success Criterion 2.1.3 (Level AAA): Keyboard (No Exception)
Success Criterion 2.5.1 (Level A): Pointer Gestures
- Supplementary Information
Checklist Items
Check ID: 0172
When moving the focus, the focus moves in a natural order that is consistent with the context, layout, and operating procedures among the following components.
Links and Buttons
Form controls
Everything else that accepts mouse, keyboard, or touch operation
- Applicable Stages
Product
- Target Platforms
Web, Mobile
- Severity
[NORMAL]
Check Procedure: Web
Confirm 0172-keyboard-01 passes below.
0172-keyboard-01: An Example of Performin the Check with Keyboard
Confirm the following by moving the focus using Tab key, or Shift+Tab key:
The focus moves to all the links, buttons, form controls, and components that accepts operation.
The focus moves in a natural order that is consistent with the context, layout, and operating procedures.
Check ID: 0581
For UI components that require custom implementation, the behavior when using screen readers and the behavior when operating with a keyboard are explicitly stated in the design documentation.
- Applicable Stages
Design
- Target Platforms
Web, Mobile
- Severity
[CRITICAL]
Check ID: 0586
Custom UI components are implemented so that their roles and states are appropriately conveyed to assistive technologies such as screen readers.
- Applicable Stages
Code
- Target Platforms
Web, Mobile
- Severity
[CRITICAL]
Implementation Example: Conveying Roles to Screen Readers
- Web
Specify the
roleattribute appropriately.- iOS
Specify the appropriate
accessibilityTraits.
- Android
If using jetpack compose: Specify the
roleattribute appropriatelyIf not using jetpack compose: Override the
getAccessibilityClassName()method of the view to return an appropriate value.
Check ID: 0956
Radio buttons can be operated using the keyboard.
- Applicable Stages
Product
- Target Platforms
Web
- Severity
[MAJOR]
Check Procedure: Web
Confirm 0956-keyboard-01 passes below.
0956-keyboard-01: An Example of Performin the Check with Keyboard
Perform keyboard operations and confirm that all of the following are met:
Radio buttons are grouped in appropriate units, such as choices for the same question, and when moving the focus using the Tab/Shift+Tab keys, the focus moves to only one radio button in each group.
When the focus is on a radio button in a group, the selection state of the radio buttons in the group can be changed using the arrow keys, and the focus moves to the selected radio button.
When the selection state of a radio button is changed using the arrow keys, the state of a radio button that does not belong to the group is not affected or the focus does not move to such a radio button.
Check ID: 0957
Check boxes can be operated using the keyboard.
- Applicable Stages
Product
- Target Platforms
Web
- Severity
[MAJOR]
Check Procedure: Web
Confirm 0957-keyboard-01 passes below.
0957-keyboard-01: An Example of Performin the Check with Keyboard
Perform keyboard operations and confirm that all of the following are met:
There are no check boxes that cannot be reached when moving the focus using the Tab/Shift+Tab keys.
The on/off state of the focused check box can be toggled by pressing the space key.
Appropriate Focus Order
When the focus is moved using the Tab/Shift+Tab keys, move the focus in an appropriate order that matches the meaning of the content.
- Target Platforms
Web
- Intent
Enable assistive technologies such as screen readers to correctly recognize content and present it to users in an appropriate manner.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.4.3 (Level A): Focus Order
- Supplementary Information
Checklist Items
Check ID: 0172
When moving the focus, the focus moves in a natural order that is consistent with the context, layout, and operating procedures among the following components.
Links and Buttons
Form controls
Everything else that accepts mouse, keyboard, or touch operation
- Applicable Stages
Product
- Target Platforms
Web, Mobile
- Severity
[NORMAL]
Check Procedure: Web
Confirm 0172-keyboard-01 passes below.
0172-keyboard-01: An Example of Performin the Check with Keyboard
Confirm the following by moving the focus using Tab key, or Shift+Tab key:
The focus moves to all the links, buttons, form controls, and components that accepts operation.
The focus moves in a natural order that is consistent with the context, layout, and operating procedures.
Behavior When Focused
Do not use form controls or components that, upon receiving focus, change the meaning of the content or cause dynamic changes affecting the entire page.
- Target Platforms
Web, Mobile
- Intent
Do not cause behaviors that are unexpected for users with visual or cognitive impairments.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 3.2.1 (Level A): On Focus
- Supplementary Information
Checklist Items
Check ID: 0152
The design documentation does not include features that cause the following changes when moving focus using the Tab/Shift+Tab keys:
Form submission
Layout changes
Page transitions
Display of modal dialogs
Significant changes in displayed content, etc.
- Applicable Stages
Design
- Target Platforms
Web
- Severity
[CRITICAL]
Check ID: 0171
Behavior when moving focus using tab/shift+tab keys fulfills all of the following
Focus indicator or alternative display is present
The following behaviors do not occur automatically:
Form Submission
Layout Changes
Page Transitions
Display of modal dialogs
Significant changes in displayed content
- Applicable Stages
Product
- Target Platforms
Web
- Severity
[CRITICAL]
Behavior When the Value of a Form Field Changes
Do not create form fields that, when their values are changed, lead to changes in the meaning of the content, significant alterations across the entire page, or changes in the values of other form fields. Alternatively, inform users in advance about the behavior of such form fields.
- Target Platforms
Web, Mobile
- Intent
Do not cause behaviors that are unexpected for users with visual or cognitive impairments.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 3.2.2 (Level A): On Input
- Supplementary Information
Checklist Items
Check ID: 1051
There are no functions in the design documentation where changing the value of a field in a form, or moving the focus after changing a value, triggers significant changes to the display content affecting the entire page/screen, page/screen transitions, or changes to the values of other fields.
- Applicable Stages
Design
- Target Platforms
Web, Mobile
- Severity
[CRITICAL]
Check ID: 1071
Manipulating form controls, such as edit boxes, checkboxes, radio buttons, buttons, etc., within the page/screen doesn not cause behavior such as:
The display content changes significantly.
Automatic transition to another page/screen
The content of a field already entered by the user is automatically changed (especially undesirable if the field being changed is located before the field that was manipulated).
- Applicable Stages
Product
- Target Platforms
Web, Mobile
- Severity
[CRITICAL]
Identify Errors by Text Information
When there are input errors, notify the user of the error location and error content by text.
- Target Platforms
Web, Mobile
- Intent
Enable individuals with visual impairments or color vision deficiencies to identify error locations.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 3.3.1 (Level A): Error Identification
- Supplementary Information
Checklist Items
Check ID: 1081
The design documentation explicitly specifies the specific phrases that are displayed when an error occurs in form input, clarifying the nature of the error.
- Applicable Stages
Design
- Target Platforms
Web, Mobile
- Severity
[NORMAL]
Check ID: 1101
When an error related to form entry occurs, text information that specifically identifies the nature of the error is displayed.
- Applicable Stages
Product
- Target Platforms
Web, Mobile
- Severity
[NORMAL]
Suggestion for How to Correct Errors
When there are input errors, indicate methods for correction.
- Target Platforms
Web, Mobile
- Intent
Mitigate the difficulties faced by individuals with cognitive and learning disabilities in form input.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 3.3.3 (Level AA): Error Suggestion
- Supplementary Information
Checklist Items
Check ID: 1111
The design documentation explicitly specifies error messages that indicate how to correct errors in form input.
- Applicable Stages
Design
- Target Platforms
Web, Mobile
- Severity
[NORMAL]
Check ID: 1131
Error messages related to form entry indicate how to correct the error.
- Applicable Stages
Product
- Target Platforms
Web, Mobile
- Severity
[NORMAL]
Prevention of Misoperation
For functions involving legal commitments, financial transactions, or the alteration or deletion of data, enable cancellation, pre-submission confirmation and modification, or error checking and correction at the time of submission.
- Target Platforms
Web, Mobile
- Intent
Minimize the impact of misoperation.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 3.3.4 (Level AA): Error Prevention (Legal, Financial, Data)
- Supplementary Information
Checklist Items
Check ID: 1141
For functions that involve legal actions, financial transactions, or the modification and deletion of data, the design allows for cancellation, pre-submission confirmation and modification, or error checking and correction at the time of submission.
- Applicable Stages
Design
- Target Platforms
Web, Mobile
- Severity
[MAJOR]
Sufficiently Large Click/Touch Targets
When changing the appearance of form controls from the browser’s default, ensure that the click/touch targets are sufficiently large.
For desktop web, 24 x 24 CSS px or larger, preferably 44 x 44 CSS px or larger.
For mobile web, 44 x 44 CSS px or larger.
- Target Platforms
Web
- Intent
Prevent erroneous clicks/touches for users with low vision or those with physical disabilities that make fine hand movements difficult.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.5.5 (Level AAA): Target Size
- Supplementary Information
Checklist Items
Check ID: 0332
When altering the appearance of form controls such as checkboxes, radio buttons, and buttons from the browser’s default, the area responsive to clicks or touches is sufficiently large, and this area is explicitly specified in the design documentation.
For desktop Web, at least 24 x 24 CSS px, preferably more than 44 x 44 CSS px
For mobile Web, more than 44 x 44 CSS px
- Applicable Stages
Design
- Target Platforms
Web
- Severity
[NORMAL]
Check ID: 0352
Form controls, such as checkboxes, radio buttons, buttons, etc., have large enough area that responds to clicks and touches, when their appearance is changed from the browser default.
for desktop Web: at least 24 x 24 CSS px, preferably larger than 44 x 44 CSS px
for mobile Web: larger than 44 x 44 CSS px
- Applicable Stages
Product
- Target Platforms
Web
- Severity
[NORMAL]
Sufficiently Large Click/Touch Targets (Mobile)
Ensure that the touch targets for interactive elements are sufficiently large.
44 x 44 CSS px or larger, or
A size that meets the interface guidelines of the operating system.
- Target Platforms
Mobile
- Intent
Prevent people with low vision and people with disabilities who have difficulty with fine motor control from making erroneous clicks/touches.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.5.5 (Level AAA): Target Size
- Supplementary Information
Checklist Items
Check ID: 0334
Form controls such as checkboxes, radio buttons, buttons, and other interactive elements have a sufficiently large area responsive to clicks or touches, and this area is explicitly specified in the design documentation.
- For iOS:
44 x 44 px (as specified in the OS’s UI guidelines)
- For Android:
Tap size at 48 x 48 px with an 8px space visually (as specified in the OS’s UI guidelines)
Visually, ensure a height of 36px for horizontally elongated shapes and 40px for square shapes
- Applicable Stages
Design
- Target Platforms
Mobile
- Severity
[NORMAL]