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.
Input Devices
These guidelines are for all content to enable the use of various input devices.
Enable Keyboard Operation
Do not create functions that cannot be executed without using a mouse or touch UI, and ensure that operation by keyboard is also possible.
- Target Platforms
Web
- Intent
Ensure that users with visual impairments or physical disabilities who cannot or do not use a mouse can use content.
- 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 the following check by keyboard passes.
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: 0211
Elements that accept mouse actions such as clicks or mouseovers are designed to be operable with the keyboard alone.
- Applicable Stages
Design
- Target Platforms
Web
- Severity
[MAJOR]
Check ID: 0231
Anything that accepts mouse operation, such as clicks and hover, can also be operated using only the keyboard.
- Applicable Stages
Product
- Target Platforms
Web
- Severity
[MAJOR]
Check ID: 0361
Design such that information displayed or functions executable on mouseover can also be displayed or executed when operating solely with a keyboard, or with a touch UI.
- Applicable Stages
Design
- Target Platforms
Web
- Severity
[MAJOR]
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.
Support for Mobile Assistive Technologies
When using the standard screen readers of the OS, the following must be met:
All UI components that receive operations can be focused on and operated by the screen reader.
All information displayed on the screen can be focused on by the screen reader and its content can be read.
The display indicating the focus area of the screen reader is in a color scheme that is visible.
The standard screen readers for the OS refer to VoiceOver for iOS and iPadOS, and TalkBack for Android.
- Target Platforms
Mobile
- Intent
Ensure that people with visual impairments can use content.
Enable the use of assistive technologies other than screen readers, such as voice input and switch interfaces.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 1.4.11 (Level AA): Non-text Contrast
Success Criterion 4.1.2 (Level A): Name, Role, Value
Checklist Items
Check ID: 0153
The color scheme is designed to make it possible to see the color that indicates the focus area of the screen reader.
- Applicable Stages
Design
- Target Platforms
Mobile
- Severity
[CRITICAL]
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: Mobile
Confirm that the following checks by iOS VoiceOver and Android TalkBack pass.
An Example of Performin the Check with iOS VoiceOver
Confirm the following by moving the focus with one-finger left/right flicks:
Selected state moves in a natural order that is consistent with displayed content and its meaning.
Nothing besides text displayed on the screen and the alternative text of images being displayed is announced.
Everything displayed on the screen is announced.
An Example of Performin the Check with Android TalkBack
Confirm the following by moving the focus with one-finger left/right flicks:
Selected state moves in a natural order that is consistent with displayed content and its meaning.
Nothing besides text displayed on the screen and the alternative text of images being displayed is announced.
Everything displayed on the screen is announced.
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.
Appropriate Focus Order
When moving focus using keyboard operations like Tab/Shift+Tab keys, or touch UI left/right flick operations with screen readers, ensure that focus moves in an appropriate sequence that aligns with the content’s meaning.
- Target Platforms
Web, Mobile
- Intent
Ensure that users of assistive technologies such as screen readers and users who operate only with a keyboard can use content appropriately.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 1.3.2 (Level A): Meaningful Sequence
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 the following check by keyboard passes.
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 Procedure: Mobile
Confirm that the following checks by iOS VoiceOver and Android TalkBack pass.
An Example of Performin the Check with iOS VoiceOver
Confirm the following by moving the focus with one-finger left/right flicks:
Selected state moves in a natural order that is consistent with displayed content and its meaning.
Nothing besides text displayed on the screen and the alternative text of images being displayed is announced.
Everything displayed on the screen is announced.
An Example of Performin the Check with Android TalkBack
Confirm the following by moving the focus with one-finger left/right flicks:
Selected state moves in a natural order that is consistent with displayed content and its meaning.
Nothing besides text displayed on the screen and the alternative text of images being displayed is announced.
Everything displayed on the screen is announced.
Visualization of Focus Areas
Do not remove focus indicators from elements that can be operated by keyboard.
- Target Platforms
Web
- Intent
Ensure that the focused area is discernible and operable even when using only a keyboard.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.4.7 (Level AA): Focus Visible
- Supplementary Information
Checklist Items
Check ID: 0151
When not using the default focus indicator, an alternative focus indicator is explicitly specified in the design documentation.
- 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]
Avoid Keyboard Traps
Ensure that focus can be moved off from every component on a page using simple operations such as pressing the Tab key, arrow keys, and Esc key.
- Target Platforms
Web
- Intent
Ensure that specific components on a page do not prevent access to other parts of the page when using only a keyboard.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.1.2 (Level A): No Keyboard Trap
- Supplementary Information
Checklist Items
Check ID: 0201
When moving the focus using Tab/Shift+Tab keys, the focus does not get stuck at certain location, or
If the focus gets stuck at certain location, simple operation such as pressing arrow keys or Esc key gets the focus away from the location
Examples of components that require special caution:
audio and/or video players
pop-up menus
modal dialogs
- Applicable Stages
Product
- Target Platforms
Web
- Severity
[CRITICAL]
Check Procedure: Web
Confirm the following check by keyboard operation passes.
An Example of Performin the Check with Keyboard
Use the Tab key to sequentially move the focus from the top of the page and confirm the following:
Pressing the Tab key or Shift+Tab key does not cause a situation where the focus cannot escape from a specific location, or
If the focus cannot escape by pressing the Tab key or Shift+Tab key, it is possible to remove the focus from the corresponding location with simple key operations such as the arrow keys or the Esc key.
Do Not Use Down Events as Triggers
For functions that are executed by clicking or tapping, use up events (like mouseup, touchup) or click events (like click) instead of down events (like mousedown, touchdown) as triggers for execution and completion. This allows for the interruption of accidental operations.
- Target Platforms
Web, Mobile
- Intent
Minimize the impact of accidental actions with pointing devices and touch UI taps.
If you accidentally press the mouse button in an unintended place, you can cancel the operation by releasing the button outside of the target area.
In drag & drop operations, if the mouse button is pressed in the wrong place, moving the mouse pointer back to its original position and then releasing the button can cancel the drag & drop action.
In touch UI, if you accidentally touch an unintended area, moving your finger off the target and then releasing it can cancel the operation.
For drag & drop operations in touch UI, if you touch the wrong place, moving your finger back to the original position and then releasing it can cancel the drag & drop action.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.5.2 (Level A): Pointer Cancellation
- Supplementary Information
Checklist Items
Check ID: 0071
The mouse button’s down event is not used as a trigger.
- Applicable Stages
Code
- Target Platforms
Web
- Severity
[NORMAL]
Check ID: 0081
In objects that accept mouse clicks, such as links and buttons, it is possible to cancel the operation even after pressing the mouse button.
Note：Objects for drag and drop are not subject to this check.
- Applicable Stages
Product
- Target Platforms
Web
- Severity
[NORMAL]
Check Procedure: Web
Confirm that no functionality is executed upon performing the following:
Move the mouse pointer onto the object
Press the mouse button
Move the mouse pointer outside the object while holding down the mouse button
Release the mouse button
Do Not Assume Specific Input Devices
There are no inaccessible pieces of information or unusable functions that require non-standard input methods for that platform.
Standard input methods for the platform refer to the keyboard for the web, and OS-standard touch operations for mobile. Additionally, for text input, touch operations on Windows, and operations using a connected keyboard on iOS or Android, are also considered standard input methods for the platform.
- Target Platforms
Web, Mobile
- Intent
Do not hinder the use of diverse input methods tailored to different needs.
By not impeding the use of keyboards on smartphones, in addition to touch UIs, the burden on users with upper limb disabilities or visual impairments can be reduced.
By not creating functions that can only be executed through operations that assume motion, such as using an accelerometer (for example, shake to undo), the use by users with physical disabilities is not hindered.”
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.5.4 (Level A): Motion Actuation
Success Criterion 2.5.6 (Level AAA): Concurrent Input Mechanisms
- Supplementary Information
Checklist Items
Check ID: 0362
There are no features or information that can only be accessed by using methods other than standard touch operations, such as shaking the device.
- Applicable Stages
Design
- Target Platforms
Mobile
- Severity
[MAJOR]
Check ID: 0371
In situations where the user inputs text, such as in edit boxes or custom-implemented components for entering passwords, input via an external keyboard is possible, regardless of when the external keyboard is connected.
- Applicable Stages
Code
- Target Platforms
Mobile
- Severity
[MAJOR]
When Providing Shortcut Keys
When providing shortcut keys, satisfy one of the following:
Allow users to disable shortcut keys.
Allow users to change the assignment of shortcut keys.
Enable shortcut keys only when the target of the operation has focus.
- Target Platforms
Web
- Intent
Ensure that functions assigned to shortcut keys are not executed accidentally when operating with voice recognition.
- Corresponding Success Criteria of WCAG 2.1
Success Criterion 2.1.4 (Level A): Character Key Shortcuts
- Supplementary Information
Checklist Items
Check ID: 0141
If there are shortcut keys that work regardless of which part of the screen the focus is on, one of the following is true
Users can disable the shortcut keys
Users can change shortcut assignments
- Applicable Stages
Product
- Target Platforms
Web
- Severity
[NORMAL]