Learning objectives:

1. Understand the pivotal role AI plays in crafting cutting-edge accessible technologies.
2. Learn about innovative AI tools that empower individuals with disabilities.
3. Dive into best practices for creating inclusive AI solutions.
4. Explore the exciting future of AI in pushing the boundaries of accessibility

https://www.youtube.com/watch?v=H736Y3U3cmE

They break down their approach in three areas:

1. richness for search engines,
2. availability for knowledge engines, and
3. connectivity into bespoke digital assistant “skills.”

Also worth noting: Google is using AI to find the most compelling content. I’m curious to see how that shakes out too.

Early last year, a cry for help on Stack Overflow drew my attention:

I’ve been trying to make my site … work fully without JavaScript, however, I’ve found myself in situations where I can’t honestly think how I would do some features without it.

The submitter, JamHam, is certainly not alone in feeling this way. The ways we build websites change all the time. When I started out, it was pretty simple: you had HTML. Lots and lots of HTML. We also had Java applets, then Shockwave and Flash. Then we got some very basic stylesheet support. Then JavaScript.

As the years pressed on, the three major technologies underpinning the Web—HTML, CSS, and JavaScript—evolved and became even more powerful.

Things coalesced for a while in the early oughts before Jesse James Garrett re-christened a relatively obscure Microsoft creation, XMLHttpRequest, “AJAX” and set countless designers hearts aflutter with the promise of banishing the page refresh. At the heart of this revolution was JavaScript, and companies began betting their entire Web presence on its availability. Most learned that wasn’t such a good idea and began using it as an enhancement to the experience rather than a requirement.

After Ajax, there was HTML5, CSS3, and a host of new JavaScript APIs… the JavaScript frameworks—Angular, Knockout, Backbone, Ember, React… The ways we can create Web products just keep changing; sometimes slowly, but more often than not at such a speedy clip it leaves my head spinning.

The one thing I’ve learned however, being an “old man” in Web terms, is that web design is cyclical, just like everything else. The challenges we face building web products today are not new challenges. Moreover, the lessons we learned building similar products in the “Web 1.0” days pay dividends today and will continue to do so in the future.

When I started out on the Web, I had a 28.8 kbit/s modem, but still had to support users on 14.4 kbit/s connections. That’s half the speed I was used to running at. That may have been 20 years ago, but the lessons I learned about streamlining my HTML, optimizing images, and minimizing downloads has helped me immeasurably when dealing with high-latency mobile networks and excruciatingly slow “broadband” connections.

(I’m looking at you, every hotel ever.)

When I started out on the Web, I had an 800x600 monitor, but still had to support 640x480 screen resolutions. I learned the importance of prioritizing content long before media queries and flexbox enabled us to adapt our layouts on the fly. And while our computer screens keep getting bigger, mobile devices and wearables present the very same challenges I was tackling with 640x480, but in even tighter confines.

When I started out on the Web, there was no JavaScript. All calculations, data processing, and dynamic functionality had to be handled by the server. I learned how to process web forms in Perl, later trading in my CGI scripts for PHP, Ruby, and Python. And while the vast majority of our users today have JavaScript baked into their browsers, I still rely on server-side fallbacks because I recognize that we don’t control the execution environment on the open Web.

The Web is the most hostile software engineering environment imaginable.
— Douglas Crockford

You’re a savvy bunch, so I’m sure none of this is news to you, but I wanted to set the stage for what I’m really here to talk about. There’s a new cycle about to hit us and chances are you might not be thinking about it yet: Voice.

# I: The Headless UI

Science fiction has often been a strong predictor of our technological future. HAL 9000 from 2001: A Space Odyssey is probably the most (in)famous example of a computer that interacts with its users largely via voice. As a concept, the “talking computer” has appeared time and time again in space-age fiction—everything from Red Dwarf to Interstellar.

To function in the real world like they do on TV and in the movies, computers need two capabilities: Natural language processing (to understand what we say) and speech synthesis (to communicate, aurally, back to us).

Natural language processing has its roots in the 1950s, but many of these early speech models were limited because they were built around a series of hard-coded rules that the computers followed. In the 1980s, however, machine learning and real-time statistical analysis became possible.

As hardware capabilities continued to improve and computers became more powerful, they got better at recognizing the words we were saying to them. Eventually, and with enough processing power, they also began to assign meaning to words and could react accordingly.

As the years marched on, the overhead required to enable our projects to listen to our users has dropped significantly.

Listening is great, but true communication is bidirectional. Humans have been experimenting with speech synthesis since the late 1700s, but it wasn’t until the 1980s that we got a decent result though. By the 1990s, reasonably intelligible text-to-speech software was being rolled out alongside most operating systems as a core component of their assistive technology offerings: The “screen reader”. At present, screen readers are probably the best indicator of what the future of voice interaction will sound like.

When combined, the ability of a computer to listen and respond gave rise to virtual personal assistants like Siri, Cortana, Alexa, and more.

Over time, our customers will become more accustomed to and reliant on voice-based interactions with their computers and the Web. Enabling them to complete critical tasks without a visual user interface will be crucial for the long-term success of our Web-based products.

So how do you design a “headless” UI? That’s easy: You design the conversation.

# II: Interface is Conversation

Let’s take a trip back in time to one of the earliest computer games: Zork. Zork was written between 1977 and 1979. It’s a text-based adventure game that operates a lot like a game of Dungeons & Dragons—with the program serving the role of gamemaster.

West of House
You are standing in an open field west of a white house, with a boarded front door.
There is a small mailbox here.

> open mailbox

As you move from location to location throughout the game, the program describes the environment and notes objects and people you can interact with. You type what you want to do and the program tells you the results of your actions.

As this was the early days of computer gaming, you might think Zork’s interactions would be simple noun-verb combinations—“kill troll”—but Zork was more sophisticated than that. Its parser was could understand far more complex commands like “hit the troll with the Elvish sword”. This made the experience far more natural, as if you were playing a table top game with friends.

Whether Zork or a webpage, every interface is a conversation—we engage our users directly in an effort to inform them, entertain them, or persuade them to act in a particular way. How this conversation goes directly affects the experience our users have.

Let’s look at a few web page and interface component types to identify the kinds of conversations we trying to have with our users in each:

• Homepage
  We’ve just met and I’m explaining what you can do on my site (and, in some cases, why it matters).
• Contact Form
  You’re asking or telling me something. I want to help you. It’s common courtesy for me to let you know how long it may take me to get back to you with a response; and for me to abide by that.
• Product Page
  I’m explaining what a particular object or service is, what it does, and how it will benefit you. I should “show” you why something is great rather than “tell”-ing you that it is because you’re immune to salesy BS.
• Status Update
  I may prompt you with a question, but I’m here to listen. The floor is yours. (But I’m probably mining what you say for data so I can market to you later.)

When we approach interfaces as conversations, we humanize our products and improve our users’ experiences. When we don’t, things can fall apart quickly…

Over the 2011 holidays, Facebook users were uploading photos like crazy. In the span of a few days, Facebook processed more photo uploads than are contained in the entirety of Flickr. Seriously, that’s a lot of photos.

One unintended consequence of this deluge of photo uploads was a significant uptick in people asking Facebook to remove specific ones. Facebook received millions of these “photo reports”, but they made no sense: Moms holding babies reported for harassment, pictures of puppies reported for hate speech, and so on. Roughly 97% of these photo reports were dramatically mis-categorized.

Facebook’s engineers reached out to some of the users who had reported these photos to get a bit more background regarding their submissions. At the time Facebook’s photo reporting interface provided a list of reasons users could choose from if they wanted a photo removed, but, as Facebook soon discovered, many of the reports were made because users didn’t want the photo posted for reasons other than those provided. In some cases, it was because they didn’t like how they looked in the photo. In others, it was because the photo was of an ex-partner or even a beloved pet they’d shared with an ex-boyfriend or ex-girlfriend.

The existing photo reporting tool had not done a good job of accounting for these more personal reasons for wanting a photo removed, so the Facebook engineers went to work. They added a step that asked How does this photo make you feel? The options were simple:

• Embarrassing
• Upsetting
• Saddening
• Bad Photo
• Other

The “other” option also provided a free-response text field to fill in.

With this system in place, they found that 50% of reporters who answered the new question chose one of the provided options. That was pretty helpful, but there was still a problem: 34% of the “other” respondents were writing “It’s embarrassing” in the blank rather than choosing the “embarrassing” option already provided.

What the Facebook team realized was that people were not identifying with the “embarrassing” text (or may have even thought it was referring to them, rather than assuming an implied “It’s”). A subtle shift in language was needed, so they changed the label to Please describe the photo and they updated the options to mirror how people actually talk:

• It’s embarrassing
• It’s a bad photo of me
• It makes me sad

With this subtle change, they were able to increase the percentage of photo reporters who chose one of the options provided to a whopping 78%.

Words matter. Even in something as simple and banal as a form, the words we choose set the tone for our users’ experiences and often have an affect on what they do… or fail to do.

The text of our interfaces—especially form labels and responses—is just one small part of the content picture, but it’s a perfect example of how easy it can be to overlook conversation in our interfaces. There are many other types of content like product descriptions, marketing copy, legal statements, visualizations, video, audio, and more. Content is where experience begins. It’s the core that we seek to progressively enhance. It’s also the foundation upon which the voice-based experiences of the future will be based.

The more time and consideration we put into how our interfaces read, the better-positioned we will be to succeed in the future of headless UIs. Once stripped of its beautifully-crafted, responsive layout, engaging animations, and artful illustrations, does your site hold up?

Back in 2006, Dustin Diaz proposed CSS Naked Day—a day when sites could be stripped of their visual design to showcase their content, semantics, and organization.

It will be a test case to see how usable your website is to others without a “design”.
—Dustin Diaz

“Design”, as Dustin was refering to it, is the visual design of a site, but design is not solely concerned with visual representations. Diving into etymology for a moment here, design comes from the Latin designare meaning “to mark out or indicate”. The purpose of design is not to make something pretty, it’s to clarify.

If the words we use form the basis of the conversations we have with our users, the semantics we employ clarify that meaning. Choosing elements with semantic value enriches our content, illuminating the meaning and intent of our words in order to overcome the limitations of text and bring it up to par with spoken language. After all, they may look the same visually, but there’s a big difference between these two statements:

<p>I <em>really</em> want to be your friend.</p><p>I <iclass=“sarcasm”>really</i> want to be your friend.</p>

Beyond using markup to clarify the intent of the words we write, we can use it to spell out relationships that are often represented visually. Dustin described one way we do this as part of the impetus for CSS Naked Day (emphasis mine):

In the spirit of promoting Web Standards along with good semantic markup and proper hierarchy structures

By “proper hierarchy”, Dustin is talking about the document outline. A document outline is created through use of heading elements (h1–h6). It provides a easy way to review the organization of our web pages and validate our source order decisions. It also helps us ensure the flow works, which is incredibly important in any conversation. It helps us get to the point, streamline our content, and remove distractions… all of which are a sign of respect to our users.

None of this is news, of course, content strategists have been recommending that we streamline our content since the dawn of the Web. Sadly, many folks didn’t heed that advice until they were forced to confront the often infuriating world of mobile. Smaller screens required focused content.

When Luke Wroblewski coined “mobile first”, he told us to focus on the core purpose each and every page. He was, in essence, telling us to focus on the conversation we are having with our users. This approach pays huge dividends on small screens, but when it comes to voice-based interactions, “the page” doesn’t really exist. Experience is the sum of each individual interaction. As part of their Alexa Skills Kit, Amazon offers a ton of recommendations for designing for voice, many of which happen to be equally useful for sighted users.

# Write for People

We don’t author content for ourselves. We write for others. If what we write frustrated or alienates our users, we’ve failed at our job. In their profoundly helpful book Nicely Said, Nicole Fenton and Kate Kiefer Lee offer numerous suggestions for how to write with the reader in mind:

• Be clear.

• Be concise.
• Be honest.
• Be considerate.
• Write how you speak.

They also make the recommendation that you read your work aloud. As we head into the world of voice-based interactions, that’s beta testing!

# Avoid Technical and Legal Jargon

When we are writing for our readers, we need to be familiar with their level of domain knowledge so we don’t frustrate or alienate them. For example, if you track error codes for issues on your site, send them to your developers, but never present them to a user.

Similarly, we should avoid legalese and write in plain language. Medium has done a great job of this with their Terms of Service.

#When Requesting Feedback, Make It Clear that the User Needs to Respond

In perhaps the most common form example, consider the label “First Name”. It’s not terribly conversational and doesn’t beg for a response. Labels like “What is your first name?” make it clear the user should respond.

<labelfor=“first_name”>What’s your first name?</label><inputname=“first_name”id=“first_name”/>

Similarly, when there’s an error, notify them of the error and, if possible, give them some clues on how to fix it.

<labelfor=“first_name”>What’s your first name?</label><inputname=“first_name”id=“first_name”aria-describedby=“first_name-error”/><emid=“first_name-error”>Without your first name, I won’t know how to address you. Could you pleaseprovide it?</em>

#When Asking a User to Choose, Clearly Present the Options

This comes into play often when dealing with forms. Ensuring radio and checkbox controls are properly associated with their labels is critical.

<inputtype=“radio”name=“agree”id=“agree_yes”value=“yes”/><labelfor=“agree_yes”>Yes</label>

You can also use the fieldset and legend elements to group the related controls, but be sure to make the legend focusable or associate it with the first focusable form control in order to ensure the question is read out.

<fieldset><legendtabindex=“0”>Do you agree to the terms of service for this site?</legend><inputtype=“radio”name=“agree”id=“agree_yes”value=“yes”/><labelfor=“agree_yes”>Yes</label><inputtype=“radio”name=“agree”id=“agree_no”value=“no”/><labelfor=“agree_no”>No</label></fieldset>

We should strive for the same sort of clarity when presenting navigation options. The HTML5 nav element enables us to semantically identify an area of the page being used for navigation. It does not, however, identify the nav element as being for navigation when encountered naturally in the flow of the document. For that reason, it can be useful to provide an textual introduction to the section, even if you choose to visibly hide it. You might even consider expanding the text of your navigation items to provide additional context.

<navid=“nav”tabindex=“0”aria-labelledby=“nav-title”><h1id=“nav-title”class=“hidden”>Here’s what you can find on this site:</h1><ul><li><ahref=“/about/”><bclass=“hidden”>A Bit </b>About<bclass=“hidden”> Me</b></a></li><li><ahref=“/notebook/”><bclass=“hidden”>Entries in My </b>Notebook</a></li>…</ul></nav>

# Prompts Should be Short, While Still Being Clear.

In a 1933 lecture at Oxford, Albert Einstein famously said

It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

Or, as Roger Sessions paraphrased it

Everything should be as simple as it can be but not simpler.

Clear and concise writing is the hallmark of great content. We need to resist the urge to write for writing’s sake. We write in the service our audience, not for ourselves.

Government websites are some of the worst offenders in this area. Consider this lovely passage:

Heavy rains throughout most of the State have given an optimistic outlook for lessened fire danger for the rest of the season. However, an abundance of lightning maintains a certain amount of hazard in isolated areas that have not received an excessive amount of rain.

It could be written far more clearly as

Heavy rains throughout most of the State have lessened fire danger for the rest of the season. However, lightning threatens isolated dry areas.

Here in the UK, the Government Digital Service has made great strides overhauling excruciatingly painful content and making it easier to read and understand. One such example is their overhaul of the Accelerated Possession process that allows landlords to evict a tenant.

The original paper form asked for the address like this

The claimant seeks an order that the defendant(s) give possession of:
(If the premises of which you seek possession are part of a building identify the part eg. Flat 3, Rooms 6 and 7)

Before requesting the type of property concerned

(‘the premises’) which is
☐ a dwelling house
☐ part of a dwellinghouse

Clear and to the point, right?

The GDS went to work and streamlined the process in plain language:

What kind of property do you want to take back?
◎ A self-contained house, flat or bedsit
◎ Room or rooms in a property.
Tenants may share kitchen or bathroom

Then they allow you to lookup the property or manually enter the address.

While not specifically designed for the future of headless UIs, this form is prepared for their eventuality.

# Ask Only Necessary Questions

We show our users respect by respecting their time. Obviously straightforward, brief writing is one way we do that, but another is to reduce the time it takes to complete a task. Many forms are brimming with fields to be filled in. In some cases, the vast majority are purely optional. And while it may be easy to spot the required fields visually, bypassing them in an aural interface can be incredibly difficult.

User experience designers have been pushing for simplified forms since… well, as long as I can remember. Users appreciate them, they tend to result in better data, and they also tend to convert better than long forms. And when it comes to voice-based interactions, they will become a necessity. No one is going to want to spend 15 minutes working their way through a 15 question registration form when all that’s required is their email address and for them to choose a password.

On a similar note, we should avoid slicing fields into multiple parts if at all possible. For instance, you still see fields like this one, asking for a US phone number, quite often:

When interacting with this construct via voice, a user will be required to supply three separate values. In order to do so, each field would require a label. Even in the States, most developers would only know how to label the first of those three boxes. (They are area code, exchange or central office code, and line number, if you’re interested.)

HTML5 introduced a host of new field types that consolidate phone numbers, dates, times, and other complex data types into single fields. Use them! As an added bonus, most enforce content validation and formatting rules for you automatically.

# Present Information in Consumable Pieces

Like computers, we humans have a finite amount of “working memory”. The amount of mental resources required to operate an interface is called its “cognitive load”. When the amount of information we need to process exceeds our capacity to handle it, we can miss important details, have trouble concentrating, and become frustrated.

We deal with cognitive load in GUI design all the time, but in voice-based interactions, there are no visuals to act as signposts and provide reminders about where we are and what we’re doing. This is why it is critical to break complicated tasks down into simpler ones and eliminate excess noise (like non-required fields). We can also reduce cognitive load by chunking search results and other list-type content into small groups, asking the user if they want more before loading and presenting them.

The top seller in the garden department is Repel Lemon Eucalyptus Natural Insect Repellent, 4-Ounce Pump Spray

Would you like to hear the rest?

# III: Future Enhancements

Paying attention to how our interfaces read is critical to success in the future of voice-based interactions. Thankfully, we already view content as the centerpiece of every progressively enhanced experience. But we can go further.

Both Microsoft and Amazon have given us the tools to voice-enable our websites beyond the HTML we present. Amazon has chosen to do this via a dedicated JSON API, through which we can “teach” Alexa “skills”. Using this API, you can enable your users to access core site functionality through the Echo, FireTV, or any other device that has integrated the Alexa Voice Service.

Microsoft has taken a slightly different approach. Using a relatively simple XML format, they have enabled us to teach Cortana new commands that tie directly into our website.

<metaname=“msapplication-cortanavcd”content=“http://myapp.io/vcd.xml”/>

All we need to do is include a meta tag pointing to an XML file that details the commands (and variations) and, when a user installs the site as a hosted app, Cortana picks up the new commands automatically. Those commands, when issued, can open a specific page or even kick off JavaScript methods in the target page.

<?xml version=“1.0” encoding=“utf-8”?><VoiceCommandsxmlns=“http://schemas.microsoft.com/voicecommands/1.2”><CommandSetxml:lang=“en-us”Name=“groupPost”><CommandPrefix>Group Post</CommandPrefix><Example>Group Post add note</Example><CommandName=“addNote”><Example>add a note {message} using group post</Example><ListenForRequireAppName=“BeforeOrAfterPhrase”>[please]add a note [that] {noteSubject}</ListenFor><Feedback>adding {noteSubject} to Group Post</Feedback><NavigateTarget=“/addNote.htm”/></Command><PhraseTopicLabel=“noteSubject”Scenario=“Dictation”></PhraseTopic></CommandSet></VoiceCommands>

We are just starting to scratch the surface of what’s possible in voice-enabling the Web, but it’s exciting to see how some companies are addressing this opportunity. It’s always interesting when things come full circle and we see how lessons we learned early on in the Web remain applicable, not matter how much or quickly things seem to change. Seeing this pattern repeat time and time again is why I’m so drawn to the philosophy of progressive enhancement; it’s not only concerned with supporting the past… it’s setting us up for success in the future.

We, as an industry, tend to have a pretty myopic view of experience. Those of us who work day-to-day in accessibility probably have a broader perspective than most, but I would argue that even we all fall short now and again when it comes to seeing the Web as others do.

# I: We are surrounded by technology

We live in a bubble. We are surrounded by technology. Most of us grew up on desktops and laptops. Most of us carry at least one device on us at all times. For some of us, it’s a smartphone of some sort. For others it might be some sort of wearable—a fitness tracker or smart watch. And I’m willing to bet that a large number of us here in this auditorium may even have three or more devices on us at this very moment. I know I do.

And our technology is some of the newest, fastest, and most fully-featured in the world. Our devices are incredibly powerful and make us even more powerful, enabling us to tackle a wide range of tasks with ease. Most of the smartphones we carry come standard with pretty impressive assistive technology built in too, from adjustable text sizes to voice assist and screen reading tools to haptic, and other forms of feedback.

And they are brimming with sensors that extend our natural abilities: GPS, cameras, accelerometers. If you’re blind, your smartphone can help you pick out a matching outfit by identifying complementary colors. It can tell you who is standing in front of you by running facial recognition software. It can help you take a photograph of a document and then read it to you.

This is amazing stuff.

And, if headlines are to be believed, the smartphone revolution is spreading like wildfire. It seems nearly every other week there is some new report about how smartphone sales are continuing to soar. Heck, no one even seems to mention the humble feature phone anymore. And if you keep up with the tech press, CPUs, GPUs, operating systems and browsers keep getting faster and faster and JavaScript is the savior of us all.

The sky is the limit!

Beyond the devices we carry with us everywhere, more and more of our homes are being assimilated into the Borg of the Internet through smart appliances and fixtures like Nest. Tools like these make it easier to control our homes (and our budgets). They empower previously dependent people to live more independent lives.

And of course there’s the coolness factor of being able to turn on your heat while on your way home from work. These advancements are incredible!

Of course, what enables all of these things to be as amazing as they are is our ubiquitous connectivity. According to Internet Live Stats, roughly 86% of Americans use the Internet. You Canadians are a wee bit more “online” at 93%.

America does have you beat when it comes to mobile connectivity: there are over 100 mobile data subscriptions per 100 individuals in the U.S. (probably because of the whole multi-device thing). Mobile connections in Canada are around 53 per 100 people. (source)

Wired connectivity is a bit lower: 30 for every 100 in the U.S. and 33 for every 100 in Canada. (source)

Connectivity is relatively cheap for you Canadians as well. You pay somewhere in the neighborhood of 39¢-$9.86 per megabyte per month. In the U.S., fees range widely from 53¢ to a whopping $41.70 per megabyte per month. (source)

Comcast and Rogers may be equally hated on our respective sides of the 49th parallel, but Comcast clearly sucks just a little bit more. (America!)

This technology and access makes it possible for us to live richer lives and post photos of our cats and kids on Instagram, but it has insulated us. We live in a fantasy world of speed, high definition, and Beats by Dre. Sadly, our experience is far from the reality most of the world lives in.

The average American takes home $3,263 a month. For the average Canadian, that figure is $2,724. By comparison, the average worker in China makes $656 a month. But that is a fortune compared to folks in India, who only take home $295 for a month of hard work. (source)

How much is an unlocked iPhone 6 again? It starts around $649. That’s more than two months salary for the average Indian. The Galaxy S5? $799 or nearly three months of hard work. In places like India, feature phones are still quite prevalent. And even when a smartphone is introduced for their market, it pales in comparison to the sort of tech we are used to seeing.

Here we have Samsung’s flagship Galaxy S5 with an amazing set of specs. A 16GB camera?! A quad-core processor?! This is the stuff of dreams for anyone who has been working with computers for more than 10 years. My first desktop was a 5150.

No not that awesome Van Halen record, this beast from IBM:

It weighted over 20 lbs, 28 lbs with two floppy drives. The screen weighed another 13 lbs and the keyboard was 6 lbs. It maxed out at 256K of memory and offered 40K of read only memory. I couldn‘t even find a spec detailing how slow the processor was, but let’s just say that the computer I began my Web career with nearly 15 years later was only a Pentium 90 with something like 16 MB of RAM.

And here, this pocket-sized computer just blows all of that out of the water.

By contrast, here we have Intex’s Cloud FX, a new phone with specs that read like the state of the art in 2007. A crappy camera, no front camera, a slow 1 GHz processor, a paltry 128 MB of RAM and barely double that in internal storage. It’s a crappy phone by our standards.

But that’s a Firefox OS phone aimed at the Indian market vs. an Android one aimed at the “developed” world. Perhaps you’d like to look at a more apples-to-apples comparison:

Here we have the BLU Dash Jr K.

Both it and the Galaxy S5 run Android 4.4 (Kitkat), but that’s where their similarities end. Look at the resolution of the Dash Jr K: 320×480 versus the 1920×1080 of the S5. Look at the processor speed. Look at the RAM.

Now, honestly, how many of you would willingly carry the Dash Jr K or the Cloud FX as your primary phone? Maybe as a laugh, maybe ironically, but I highly doubt many in our profession would subject themselves to that. Why? Because we don’t have to.

Now I don’t know your salary, but I’m willing to bet you make more money and have far more disposable income available to spend on cutting edge gadgets than most people in the world. Surely that’s the case when you compare us to China and India, but it’s equally true here in North America.

In the U.S., we see stats like “Smartphone sales accounted for nearly 85% of all mobile phone sales” and “Smartphones have reached 50% penetration” with relative frequency. But those headlines often lead us to draw incorrect conclusions about what devices people actually use to access the Web.

The dirty little secret behind that 50% penetration number is that the penetration in question was concentrated in a scant 30% of U.S. households. Kinda burying the lead if you ask me. (source)

The Pew Research Center released a study earlier this year that showed smartphone penetration in the US, broken down by income bracket. As expected, the higher the household income, the more likely you were to find someone with a smartphone.

In the < $30,000 income bracket, smartphones were found in 47% of households. But it starts to get really interesting when you cross-reference that data with how many people fall into those income brackets. (source)

$30,000 was the average income in the U.S. in 2013. And, according to the 2010 census, the overwhelming majority of American households earn less than that. (source)

Now both the Samsung Galaxy S5 and the BLU Dash are technically smartphones, but one costs $43 and the other costs $799. On a limited budget, which do you think you’d be more likely to get?

Sure, in the US, carriers subsidize phone prices, but even the subsidized $199 AT&T offers the S5 for (with a 2-year agreement) ends up costing $1319 once you factor in the $40 activation and the minimum of $45 a month for a data plan.

So again I’ll ask: On a limited budget, which do you think you’d be more likely to get?

So even if a household has a smartphone, there’s probably decent odds on it being something a little lackluster compared to what we are used to carrying.

While it may not be a big deal for us to pay $60, $100, or more a month for mobile data access with fast speeds and high bandwidth limits, that would be a burden for most people. It’s worth noting that the cheaper pay-as-you-go plans typically have substantially lower data caps, frequently cost more per megabit, and often run at far slower speeds. Accordingly, while the Galaxy S5 supports blazingly fast 4G LTE speeds, both the Cloud FX and the Dash Jr K run on 2G technology.

All of this is to say that we must be hyper-aware of how big our Web pages are. Large pages with tons of high-resolution images cost our users real money and, frankly, waste their time. Some might not even load. Big Web pages are a barrier to access.

Beyond page size, we should also be concerned with how much work we we are requiring of the browser. JavaScript-intensive sites and applications can run really poorly on devices with slow processors and minimal RAM, like the BLU Dash Jr K or the Intex Cloud FX.

These are just a few of the concerns we’re having to deal with today, and only about a third of our planet is online. There are 4.8 billion people with no Internet access. But it’s coming. And when it happens, we will likely have even more to deal with. Like language barriers.

Consider this: About 11.7% of the world speaks English as its first or second language yet 55.7% of the Web is in English. (French is spoken by roughly 1.4% of the world and 4% of the Web is in French.)

This presents some significant challenges as the Web expands into places like India and China. Only 18.61% of India’s 1.2 billion people speak English as a first, second, or even third language. In China, only about 0.73% of their 1.2 billion people speak English. Network availability is only the first of many hurdles to accessing the Web for much of the planet. (source)

We need to look beyond our technological and cultural bubble and consider how others experience the Web. As an industry, we must figure out how we can make their experiences better.

# II: We are UX professionals

We are technologists who focus on accessibility, the capacity to tackle these challenges should come naturally to us. We were drawn to this field because we empathize with the struggles of others and want to help empower them to live independently.

We are user experience professionals and yet we’re often pigeon-holed outside of that practice. Our knowledge and contributions are often seen as only being applicable for people with “disabilities.” But our purview goes way beyond helping people with less than perfect vision, hearing, or mobility. Our purview is improving Web experiences for all people, regardless of physical or mental abilities, gender, race, or language.

Our purview is user experience and we need to assert ourselves and our role in that capacity.

More than most, we understand the importance of experience, of access, of independence because we work with people for whom “little things” like the ability to press a button can be a big problem. And beyond that, we also understand that experience is not a binary thing. It is a continuum.

This is a crucial fact that the Web industry is only just beginning to come to terms with. We can help ease that transition.

We are the champions of the egalitarian dream: equality of opportunity with the understanding that it does not guarantee equality of outcome or experience. We are pragmatic idealists who want to enable everyone access to amazing products and services.

We provide tremendous business value.

But we have a lot of work to do.

Sadly, many people still don’t value accessibility. They don’t get why it is important. They see it as expensive. They see it as a “nice to have”. They see it as an add-on.

I have gotten this reaction from designers. I have gotten it from developers. I have gotten it from other user experience professionals. And I have most often gotten it from managers and business owners. I’m sure you have as well.

I once had someone tell me he didn’t need to make his website accessible because he sold televisions and “blind people don’t watch TV.” I was floored. I mean holy crap!? This guy had no idea.

I had to educate him, but I needed to do it softly. I need to explain to him that his view of “special needs” was wrong. I had to be gentle because people don’t often react well to being told their world-view is fundamentally flawed. I’m sure I’m not the only one in this room who has been in a situation like this either.

If our primary job is to empower people to live independently, our second job is surely to educate the world, not just on how to make the Web more accessible, but why it matters. We need to bring everyone into the fold.

I love exercises that create opportunities for revelation. One of my favorites originates from John Rawls. Rawls was a philosopher who used to run a social experiment with students, church groups, and the like.

In the experiment, individuals were allowed to create their ideal society. It could follow any philosophy. It could be a monarchy or democracy or anarchy. It could be capitalist or socialist. The people in this experiment had free rein to control absolutely every facet of the society… but then he’d add the twist: They could not control what position they occupied in that society.

This twist is what John Harsanyi—an early game theorist—refers to as the “Veil of Ignorance” and what Rawls found, time and time again, was that individuals participating in the experiment would gravitate toward creating the most egalitarian societies.

It makes sense: what rational, self-interested human being would treat the elderly, the sick, people of a particular gender or race or creed or color, poorly if they could find themselves in that position?

We’re often put in a box and told to only concern ourselves with folks with “special needs.” Well news flash: we all have special needs. Some we’re born with. Some we develop. Some are temporary. Some have nothing to do with us personally, but are situational or purely dependent on the hardware we are using, the interaction methods we have available to us, or even the speed at which we can access the Internet or process data.

We need to look beyond the world of assistive Web technology and explain the value and insight we bring to approaches like Responsive Web Design. After all, what is RWD about if not access? Yes, its fundamental tenets are concerned with visual design, but in terms of the big picture, they’re all about providing the best possible reading experience. Responsive web design is also a perfect example of the continuum of experience we are so intimately familiar with.

We understand special needs. We understand fallbacks. And we understand how to design robust experiences that work under a wide variety of conditions. That knowledge is invaluable.

We are invaluable.

# III: We are the future

This is an incredibly exciting time to be working in accessibility. User experience is becoming central to how organizations work and how they design their products and accessibility should be at the core of that.

This is our time!

The more influence we have on the products and services our companies and clients create, the more places they can go and the more successful they will be.

Take WhatsApp for instance. Fundamentally, it is a chat application. That’s not terribly groundbreaking. But it developed into a way to avoid costly SMS messages. Still, even that’s not all that special: the App Store lists over 7,900 messaging apps for the iPhone.

What made WhatsApp matter was the shrewd business decision to move beyond the bubble. They chose to embrace access and embrace diversity. They made their messaging application available on a ton of platforms, especially low cost ones. So sure, they support iOS and Android, but unlike a lot of app developers, they officially support Android 2.1+, iOS 4.3+, Blackberry 4.7+, Symbian, Nokia Series 40, Windows Phone. Some of those aren’t even smartphone OSes!

While many may not consider this an “accessibility” win, it absolutely is. WhatsApp made a decision to open up access to their messaging application to people who were traditionally ignored by mobile app developers. And they were rewarded handsomely for this: as of last count, they had somewhere around 600 million users globally. And then there’s that little thing about them selling to Facebook for $19 billion.

And WhatsApp isn’t a fluke in benefiting from making itself more accessible: China’s WeChat boasts a user base of 600 million and Japan’s LINE has over 400 million users. All of these messaging platforms have benefitted greatly from embracing devices and technologies available to people outside of our bubble.

We can and should be advising our companies and clients on why and how to be more accessible. We need to look at the big picture and we should not be afraid to be bold in asserting that accessibility creates opportunity.

We already know that strong content guidelines pay dividends by creating opportunities for our content to work harder for us. Not only do they improve the readability of content on the sites we build, but they facilitate social sharing through more engaging summaries and headlines.

The clear, well-written, jargon-free content we advocate for is easier to translate into other languages. It also makes the content easier to follow via screen readers and other vocalization tools like Readspeaker, which in turn makes it possible to offer novel ways of accessing our content, like automated podcasts.

Our focus on semantic, meaningful, markup allows our content to be pulled into other contexts including focused reading apps like Pocket, Readability, and Instapaper.

And while we can certainly do a lot to make rich, JavaScript-based interactions far more accessible to assistive technology, our advocacy for progressive enhancement ensures that our content and tools work no matter what.

Let’s say an ISP blocks jQuery as malware. No problem.

Let’s say the page is taking a long time to download on a high-latency mobile network (or hotel Wi-Fi). No big deal.

The products we build just work because we know that we don’t control how they are delivered.

It’s our job to educate others on this reality and to demonstrate why these are central to user experience.

# IV: We are Agents of Change

The shift to handheld computers has been huge for accessibility. After all, the computers in our pockets are assistive technology. This is our world!

I’m going to make a somewhat bold prediction: while touch has been revolutionary in many ways toward improving digital access, voice is the future. And the user experience of voice-based interfaces is going to be critical in creating more opportunities for people to interact with and participate in the digital world.

We’ve got the jump on the other folks working in user experience when it comes to voice: We’ve been considering how interfaces sound for years. On top of that, we already understand how to design alternate interaction methods because we see experience as a continuum.

As voice UX technology—for example, Siri, Google Now, and Cortana—improves, we should be the ones people should look to as the experts. We will empower the next generation of websites and applications to become voice-enabled. And in so doing, we will improve the lives of billions. Because “accessibility” is not about disabilities, it’s about access and it’s about people.

Sure, we’ll make it easier to look up movie times and purchase tickets to see the latest Transformers debacle, but we will also empower the nearly 900 million people globally—over 60% of whom are female—that are illiterate. And that’s a population we have not traditionally viewed as our purview either.

We will create new opportunities for the poor and disadvantaged to participate in a world that has largely excluded them. You may not be aware, but 80% of Fortune 500 companies—think Target, Walmart—only accept job applications online or via computers.

We will enable people who have limited computer skills or who struggle with reading to apply for jobs with these companies.

We will empower immigrants to read lease agreements and their postal mail.

We will enable people with visual disabilities to vote, even on paper ballots, without human assistance.

We can help bridge the digital divide and the literacy gap. We can create opportunities for people to better their lives and the lives of their families. We have the power to create more equity in this world than most of us have ever dreamed.

This is an incredibly exciting time, not just for the accessibility experts, not just for user experience, not just the Web, but for the world! I can’t wait to see how awesome you make it!

Thank you.