Input modes

Responsive design jolted the industry with the simple truth that the web is not limited to a single output (the desktop screen). Now comes another revelation: the web is not limited to a single input. Your app could be used on devices whose inputs include keyboard, mouse, phone pad, Kinect-style natural gesture, speech, stylus—or some combination of these. The web touches all kinds of devices, and your Orchid app should adapt gracefully to any of their input modes.

The good news is that Orchid components come with lots of accessibility features built in, and most will simply do the right thing on whatever device comes your way. But your job isn’t done there.

Why bother?

If most of your users today are on a desktop computer, then why do the extra work to support additional devices?

• Be accessible. Orchid apps should be designed to work with the assistive devices or browsers that make it possible for people with disabilities to use the web. (See Orchid’s accessibility guidelines.) Input modes include:
  • Keyboard-only (people with cognitive, physical, and visual disabilities)
  • Touchscreen-only (people with cognitive and physical disabilities)
  • Mouse and keyboard with software that compensates for hand tremor
  • Voice recognition and other hands-free interaction
• Be kind to your future self. These alternative inputs may eventually become mainstream inputs. Speech is moving quickly to become a popular interaction mode, for example. The more you support these inputs today, the less you’ll have refactor tomorrow.
• Backward compatibility is forward compatibility. Any web-browsing device can handle simple markup, no matter what the input mode. Craft your apps to work with older, “just basic HTML” devices, and they’ll naturally work well with future devices and input modes, too. That doesn’t mean you can’t use fancy JavaScript frameworks, but use progressive enhancement so that the interaction will work even if the JavaScript fails. For more on progressive enhancement, see Resilient Web Design.
• Meet your users on whatever device they bring. You don’t get to choose the device people use, and you might be surprised at what they choose. “They’ll never do that on mobile” used to be a common phrase that’s fallen away as many of us have experienced having to get something done on the only device we’ve got with us. Be ready for anything.

Touchscreens

Touch introduces physicality to designs that were once strictly virtual; for the first time, digital designers have to ask themselves, How does this design feel in the hand? Here are some guidelines to make sure your app is well behaved on touchscreens.

• Large touch targets. The ideal minimum for touch targets should be height and width of at least 44px (or 2.75rem). When space is tight, you can reduce either height or width of secondary elements to 30px (1.875rem) as long as the other dimension remains at least 44px.
• Ample spacing. Touch-target spacing is as important as size in preventing errors. The closer targets are, the larger they should be. Likewise, the smaller they are, the more you should space them out. 44px elements should be spaced by about 14px (.875rem).
• Hover is an enhancement. Hover doesn’t exist for touchscreens, of course, so hovering over an element can’t be the only way to access information. Consider hover content to be a nice-to-have convenience, a shortcut to preview content on devices that support it. That content should still be available somehow without hover, even if not as a convenient shortcut.
• Consider ergonomics. A touchscreen is a physical interface that requires people to reach, stretch, press. Just as if you were designing a hardware device, you have to consider your interface’s comfort in the hand. It’s not just how your pixels look, it’s how they feel. Place primary controls within each reach of fingers and, especially, of thumbs. See How We Hold Our Gadgets for an introduction.
• Reduce the number of taps. Physical interfaces take physical work to operate. The larger the touchscreen, the more effort and precision it requires. Save people time and elbow grease by reducing the number of taps and interactions needed to move through your design. Select menus, text entry, carousels, and other web widgets swing from easy convenience with a mouse to a dreary burden on touchscreens.
• Avoid select menus. It takes two taps just to summon and dismiss a select menu in a touchscreen, followed by several swipes and some fine-tuning to make the selection. It’s a touch-hostile experience. Alternatives include single-tap radio buttons for a small set of options.

Keyboard only

Power users often prefer keyboard commands for efficiency, while people with motor impairments or visual disabilities rely on the keyboard because they can’t use a mouse.

When people navigate via keyboard, access is sequential: you must tab through all the links one by one before getting to your destination. A mouse user, by contrast, can move the cursor directly to the link they want to click. Here are some pointers for handling that sequential input mode:

• Make keyboard focus obvious. Keyboard focus is coded by default into all the common web browsers, usually with a border around the focused element. Removing that focus indicator makes keyboard navigation impossibly hard; you have no idea where you are. If you don’t like the browser’s default focus appearance, you may replace it with a treatment that is consistent with your app’s look and feel, as long as the role remains obvious. Orchid components already do this for you, however; no need to edit focus appearance unless you’re building your own component from scratch. If you do this, look to Orchid’s components for suggested treatment.
• Set navigation order. The tab order of your page elements has to be intuitive and predictable. As much as possible, structure your underlying source code so that the reading/navigation order is predictable. Use tabindex attributes to adjust tab order as necessary.
• Make all interactive elements available via tabbing. Your app has to allow any interactive element to be focused by tabbing, or there’s no way to select it. The browser will handle most interactive elements correctly; the trouble is when you build your own out of <div> elements or other typically non-interactive elements. Fix this by adding tabindex attributes to custom controls.

Speech

Speech navigation follows many of the same rules as keyboard-only navigation. Adopting the best practices described above will take care of many speech-navigation issues, too. There are a few special areas to mention that are specific to speech, however, particularly affecting how speech browsers read the site back to users.

• Alt text on images. Add alt text to all images or any visual elements that have content meaning (not purely decorative).
• Add proper table and column headers to data tables. Orchid’s default table markup shows you how to do this, nudging voice browsers to identify the name of the column or row that the user is currently browsing.
• Label your forms. When you use the <label> element to associate form controls and their descriptions, speech browsers will read the appropriate label when a form element is focused. Orchid’s form controls offer good examples of this best practice.
• aria-label is your friend. Add the aria-label attribute to any element to instruct the voice browser exactly what to speak out to the user: aria-label="this is what the browser will read".

Usability testing

As you test your app, go beyond your typical desktop setup. Put your mouse away and navigate the screen with keyboard only. Test your app’s touchscreen ergonomics on many different touchscreen formats: phone and tablet, sure, but also touch- and stylus-enabled laptops and desktops. Turn on your operating system’s speech-recognition features and navigate your app with it.

When you ensure that your app robustly handles any of these common alternative input modes, you ensure that your app is available to everyone, no matter what device they use.