The Future Is Now & It’s (Mostly) Accessible

Set in the dystopian future Los Angeles 2019, the 1986 movie “Blade Runner” protagonist Rick Deckard leisurely sits back in his chair with a drink in hand, uses his voice to scan, pan, zoom a digital photo for clues:

(Yes, that is young Harrison Ford (insert heart eyes emoji)).

I don’t know about you, but my head exploded when I watched that scene because the technology depicted over 30 years ago is reality today. Dear storytellers Philip K. Dick and Sir Ridley Scott, thank you. You saw the future and nailed it: Voice Control.

Voice Control isn’t Siri or Alexa. It’s You.

Voice Control is a substitute for using your mouse/keyboard to control a computer or mobile device across applications. It’s an extension of you. As we (similarly) saw in the scene, it’s your ability to zoom in on a picture, dictate into a text box, or scan through a list of podcasts.

Voice assistants like Alexa and Siri, on the other hand, use machine learning to deliver you answers or operate tasks on your behalf. (I’ll cover this in a follow-up post.)

Accessibility Gone Mainstream

For someone with motor disabilities such as quadriplegia or ALS, Voice Control is a game changer. This technology was developed for these users in mind, but it’s gaining widespread acceptance. Voice Control is being built into the latest version of Apple IOs. And Google’s Voice Access is available for download on Android Devices.

What’s clear is that Voice Control will soon transform how we think about and approach user experience, from user flows to how we label “things” (Tech speak, “all UI controls and elements”).

How Does Voice Control Work?

When I speak commands like “tap, search” at a voice-control-enabled device, it will ‘listen’ and try to match my command to a corresponding element. For developers, this means that natural language commands should logically align with what’s ‘under the hood.’ A common accessibility issue I often come across in app and website testing are buttons that are missing labels. For example, a search icon may be listed in the code as ‘button’ vs. ‘search button.’

When properly labelled, if a user says “Search” to run a search, the system will understand which button to ‘run’ because in the code, it is labeled as such, “Search” paired up with type <button>.

Voice Control Works Best with Accessible Code

So far, so accessible.

The kicker? Voice control works best when accessibility is already ingrained into the digital experience (here’s looking at you Dominos!) You can get on this train if you implement the basic, foundational accessibility features in the code. And it’ll be that much easier for the Voice Control experience.

So if you’ve already invested in proper structure HTML, the type that allows assistive technology like a screen-reader to ‘read aloud’ contents on the screen to a user who is blind or has low vision, well done!

AirBnB is an example of a company who made a commitment to digital accessibility. As a result, their app was “ready” for a future experience with Voice Control. It was a seamless experience on my first try:

Practically, this means that elements on the screen you would normally interact with (like buttons) were developed properly, and there are no shortcuts or workarounds introduced to mimic their behavior. For instance, a developer used the actual <button> element, rather than styling a button with <divs> to make it look like a button.

For background, a screen-reader works by reading aloud the elements on the screen, such as the headings, button names, links, form fields, navigation menus, etc, and it works best when it has the right HTML and semantics in place. Voice Control is an evolution of this — the ability for users to ‘speak to’ the screen, using those human-understandable names.

A Voice Control user can also request that all labels and names be displayed, to reinforce the naming conventions and ensure a match to spoken commands:

Proper labeling and naming of all the elements on the screen creates a harmonious experience that matches expectation. When there aren’t any labels or names, the Voice Control user cannot interact with it.

Getting it Right the First Time

I checked in with some of our Phase2 Technology developers to check that my reasoning was valid, and here’s what they had to say:

 

The benefits of a design system really shine here. Collocating reusable design patterns with the semantic markup needed for the use case, practically eliminates any remaining friction. This also enables a consistent interface and application of base elements within the UI. 

Daniel Lemay

Developer

 

Using the correct element has both short and long term benefits. A button element carries through semantic information to other tools that a styled div does not. This allows for other tools both now and in the future to interact with your site better because your content and structure has meaning they can understand in a standardized way.

Chris Johnson

Vice President of Engineering

 

Tables were used for both content and layout. We made the move to using Divs for content and layout. It’s time we move to using Divs for layout and semantic tags for content and functionality. There is no more of an excuse to stick with using divs everywhere as there is for using tables everywhere. 

Brian Nash

Senior Developer

 

This is the kind of thing you should be looking for in your code reviews. It’s almost always because the developer made a simple mistake. Sometimes people don’t know there’s a difference, and a small PR comment can be an easy teachable moment. 

Caroline Casals

Developer

It’s Not Too Late

Voice Control is one of (many) examples of how accessibility has created easier and more seamless experiences for all of us. Speaking as a person with a disability, we don’t want our assistive technology to separate us, but to act as a bridge to everyone else. It’s a real delight when our experiences become yours, too.

Not sure if your site is accessible, or you’ve put off accessibility updates for ‘someday’? It’s not too late. You can make adjustments to your code to be ready when Voice Control becomes the norm.

Start first with evaluating the semantic code and ensuring that it lines up with accessibility best practices.

For further assistance, here’s a few resources to get you started. If that doesn’t help, then feel free to reach out to me on Twitter, LinkedIn, comments here, or e-mail: accessibility@phase2technology.com.

Originally published on Medium.com