Alternate Input Devices

Examples of alternative input

• Keyboard: Using a keyboard with a web experience can be faster and more efficient than using a mouse pointer for micro-repetitive tasks like copying and pasting text, or moving from a username field to a password field. Keyboard navigation is fundamentally linear, users can either move forward or backward across the interactive controls, one at a time.
• Switch: Custom switch controls can be more useful than keyboards for people with physical motor disabilities. They come in a wide variety of shapes, sizes, and complexity even though the interaction is very similar to that of a keyboard.
• Touch: Multi-touch displays are less precise than a desktop mouse or trackpad device. Larger touch targets benefit users with reduced dexterity. Providing the appropriate on-screen keyboards (alphanumeric vs numeric) reduces effort and cognitive load required for submitting information on the go.
• Voice Control (speech recognition): Voice commands can be used for a hands-free computing experience. For example, commanding an application to be opened, an on-screen control to be clicked, dictation of text into a field.

Visible focus styling

Users with low vision, color blindness, or any power users who prefer to use a keyboard for efficiency, must be able to see which interactive control is focused programmatically by the system.

It is recommended to use focus styling that has:

1. A 2 CSS pixel thick perimeter boundary
2. A contrast ratio of at least 3:1 between the same pixels of the focused and not focused states

Focus order

Keyboard navigation is a linear experience, meaning users may only navigate forward through the interactive controls on a screen, or backward. Navigating among the controls (focus order) is required to be “logical and predictable.” In most cases, this is interpreted to mean following the natural flow of content from right-to-left, top-to-bottom in RTL languages.

Skip content

“Skip” links are valuable tools that assist keyboard users’ linear experience by allowing them to jump past repetitive page header content. Skip links don’t need to be always visible, only when they are needed and currently focused.

“Skip” links may be useful in complex, split-screen designs that require users to repeatedly navigate between the two panels of content.

Hover text (Tooltips)

Any information provided on mouse hover must also be accessible without using a mouse. Canvas provides an accessible Tooltip component with 3 variants designed for all scenarios that will work with keyboards and screen readers. What are the 3 variants for?

• Default: Use this when the tooltip text is describing the purpose of the applied control
• Describe: Use this when tooltip text is supplementary to the applied control
• Muted: Use this when tooltip text is redundant to the text displayed from the applied control

Refer to the Accessibility Guidelines for Tooltips for more detail.

Keyboard shortcuts

Keyboard shortcuts can be a useful, well considered tool for enhancing a power user’s efficiency, but shortcuts are not a lifeline for an inaccessible interaction. Custom keyboard shortcuts require considerable design thinking to ensure the following:

1. Users must be educated on what the keyboard shortcut is, what it is for, and when it can be used. This requires clear documentation and in-context help within the experience.
2. Keyboard shortcuts must not conflict with any operating system commands, any web browser shortcuts, or any commands needed for assistive technology.
3. Users must be able to remap the custom shortcut, or turn off the shortcut entirely, in the event it interferes with the way they are using the system.

Touch targets

Increasing the touch target size, and spacing in between touch targets, can improve accuracy for everyone interacting with your designs on-the-go. This is especially true for people with reduced fine motor control and other physical disabilities.

• For interactive controls, the tap target should be at least 24 by 24 pixels. Controls smaller than 24 by 24 pixels should have padding around them to make the selectable area 24 by 24 pixels.
• Consider adding sufficient spacing between controls to prevent accidental selection. Spacing of at least 10 px between controls is recommended.

Focus order

The focus order of the interactive controls on screen is derived by the browser’s DOM, and keyboard navigation is required to be “logical and predictable.” CSS flex properties like flex-direction=”row-reverse” can contradict the right-to-left expectation in RTL languages.

Sticky headers and footers

The initial position of the focused control cannot be fully obscured from view by “sticky” headers and footers. While users may be able to use the arrow keys to scroll elements into view, it is unreasonable to expect users to micro-adjust the viewport scroll at each form field, and some inputs require the arrow keys to select values thus interfering with page scroll.

Keyboard traps

A “keyboard trap” occurs when it becomes impossible to leave a section of content without depending on a mouse or trackpad to proceed. Keyboard traps can be relatively uncommon, but they need to be taken very seriously as accessibility barriers when they do occur.

Manual end-to-end testing with only the keyboard is the most effective way to discover a keyboard trap in a product or feature, otherwise keyboard traps often go unnoticed.

Keyboard traps can sometimes be intentionally designed:

• Moving keyboard focus and trapping it inside a modal dialog is beneficial to the user experience. Allowing the keyboard focus to get lost underneath a modal overlay must be avoided at all costs.
• If a web application necessarily must change the standard navigation behavior of the Tab key, then providing a well documented alternative means of escaping that section of the web application is required to avoid keyboard traps. Examples of such web applications can include a text editor that supports indentation with the Tab key or a spreadsheet application that uses Tab to navigate to the next cell.

Canvas Kit Tooltip component

The HTML title attribute is not an acceptable hover text for two primary reasons:

1. title text does not appear visually on keyboard focus and thus, will not be accessible to sighted keyboard users.
2. title text often causes redundant (double) description by screen readers.

Canvas Kit’s Tooltip component was developed to address these accessibility gaps. The Tooltip component has three variants:

• default: Applies the tooltip text to an aria-label string on the wrapped component.
• describe: Applies the tooltip text to an aria-description string on the wrapped component.
• muted: No changes applied to the wrapped component. This variant will not be announced by screen readers.

Refer to the Accessibility Guidelines for Tooltips for more detail.