That framing cuts through a lot of the marketing nonsense. The promise is always that AI will help people do their jobs better. The deployment story, far too often, is that a human gets stuck reviewing machine output at impossible speed while absorbing the blame when things go wrong. That’s not augmentation; it’s a liability dump.

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

I’d like you to consider this a “yes… and” piece to complement Joe’s post. I don’t seek to refute any of what he’s saying, but rather provide some visibility to projects and opportunities where AI can make a meaningful difference for people with disabilities (PwD) across the globe. To be clear, I am not saying there aren’t real risks and pressing issues with AI that need to be addressed—there are, and we needed to address them like yesterday—but I want to take a little time to talk about what’s possible, in hopes we’ll get there one day.

# Alternative text

Joe’s piece spends a lot of time talking about computer vision models generating alternative text. He highlights a ton of valid issues with the current state of things. And while computer vision models continue to improve in terms of the quality and richness of detail in their descriptions, the results are not great. As he rightly points out, the current state of image analysis is pretty poor—especially for certain image types—and the current systems examine images in isolation rather than within the context in which they sit (a consequence of having separate foundation models for text analysis and image analysis).

These models are also not currently trained to distinguish an image that is contextually relevant (for which there should probably be a description) from one that is purely decorative. Of course this is something we humans struggle with as well… the right answer is often somewhere between the author’s intent and the user’s needs/preferences.

All of that said, there is potential in this space.

As Joe mentions, human-in-the-loop authoring of alt text should absolutely be a thing. And if AI can pop in to offer a starting point—even if that starting point is prompting you to say What is this B.S.? That’s not right at all… let me fix it—I think that’s a win.

Taking things a step further, if we can specifically train a model to analyze image usage in context, it could help us more quickly identify which ones are likely to be presentational and which ones likely require a description. That will help reinforce the importance of descriptions in the appropriate context and improve the efficiency with which authors can make their pages more accessible.

While complex images—graphs, charts, etc.—are challenging to describe in any sort of succinct way (even for humans), the image example shared in the GPT4 announcement points to an interesting opportunity here as well. Let’s say the description of a chart was simply the title of the chart and the kind of visualization it was. For example: Pie chart comparing smartphone usage to feature phone usage among U.S. households making under $30,000 a year. If the browser knows it’s a pie chart (because an onboard model verified this), imagine a world where a user could ask questions about the graphic.

• Do more people use smartphones or feature phones?
• How many more?
• Is there a group of people that don’t fall into either of these buckets?
• How many is that?

Setting aside the realities of Large Language Model (LLM) hallucinations for a moment, the opportunity to interface with image data in this way could be revolutionary for blind and low-vision folks as well as people with various forms of color blindness, cognitive disabilities, and so on. It could also be useful in an educational context to teach people who can see the chart, as authored, to read a pie chart.

Taking things a step further, what if you could ask your browser to simplify a complex chart, perhaps isolating a single line on a line graph? What if you could ask the browser to transpose the colors of the different lines to work better for the specific form of color blindness you have? What if you could swap colors for patterns? Given the chat-based interface and our ability to manipulate existing images in currently available AI tools, that certainly seems like a possible future.

Now imagine a purpose-built model that could extract the information from that chart and convert it to another format. For example, it could turn that pie chart (or better yet, a series of them) into a more accessible (and useful) format like a spreadsheet. That would be amazing!

# Matching Algorithms

Safiya Umoja Noble absolutely hit the nail on the head with the title of her book Algorithms of Oppression. While it was focused on search engines reinforcing racism, all computer models have the potential to amplify conflict, bias, and intolerance. Whether it’s Twitter always showing you the latest tweet from a bored billionaire, YouTube sending us into a Q-hole, or Instagram warping our idea of what a natural body looks like, we know poorly authored and maintained algorithms are incredibly harmful. A lot of this stems from a lack of diversity among the people who shape and/or build them. When built inclusively, however, there is real potential for algorithm development to benefit people with disabilities.

Take Mentra, for example. They are an employment network for neurodivergent people. They employ an algorithm to match job seekers with potential employers, based on over 75 different data points. On the job seeker side of things, it takes into account the candidate’s strengths, necessary workplace accommodations (and preferred ones), environmental sensitivities, and so on. On the employer side, it takes into account the work environment, communication factors related to the job, and the like. As a company run by neurodivergent folks, Mentra made the decision to flip the script when it comes to typical employment sites. They use their algorithm to propose available candidates to the companies, who can then connect with job seekers they are interested in; reducing the emotional and physical labor on the job seeker side of things.

When more people with disabilities are involved in the creation of algorithms, there is a lessened likelihood that these algorithms will be used to inflict harm on their communities. This is why diverse teams are so important.

Imagine if a social media company’s recommendation engine was tuned to analyze who you’re currently following and prioritized recommending that you follow people who talked about similar things, but who were different in some key way from your existing sphere of influence. For example, if you follow a bunch of non-disabled white male academics who talk about AI, it could suggest you follow academics who are disabled or aren’t white or aren’t male who also talk about AI. If you took its recommendations, you’d likely get a much more holistic and nuanced understanding of what is happening in the AI field.

# Other Ways AI Helps PwD

If I weren’t trying to put this together between other tasks, I’m sure I could go on, ad infinitum, providing all kinds of examples of how AI can be used to the benefit of people with disabilities, but I’m going to make this last section into a bit of a lightning round. In no particular order:

• Voice preservation. You may have seen the VALL-E paper or Apple’s GAAD announcement or you may be familiar with offerings from Microsoft, Acapela, and others. It is possible to train an AI model to replicate your voice, which is tremendous for people who have ALS/MDN and other medical conditions that lead to dysarthria. This is, of course, the same tech that can be used to create audio deepfakes, so it’s something we need to approach responsibly, but the tech has truly transformative potential.
• Voice recognition. Researchers like those in the Speech Accessibility Project are paying people with disabilities for their assistance in collecting recordings of people with atypical speech. As I type, they are actively recruiting people with Parkinson’s and related conditions and they have plans to expand this to other etiologies as the project progresses. This research will result in more inclusive data sets that will enable more people with disabilities to use voice assistants, dictation software, and voice response services as well as control their computers and other devices more easily, using only their voice.
• Text transformation. The current generation of LLMs is quite capable of making adjustments to existing text content without injecting hallucinations. This is hugely empowering for people with cognitive disabilities who may benefit from a text summary or the text being simplified or even from it being prepped for bionic reading.

# The Importance of Diverse Teams and Data

Of course to do things like this, we need to recognize that differences do matter. Our lived experiences are influenced by the intersections of identity in which we exist. Those lived experiences—with all of their complexity (and joy and pain)—are valuable inputs to the software, services, and societies we shape. They need to be represented in the data we use to train new models and the folks who contribute that valuable information need to be compensated for sharing it with us. Inclusive data sets yield more robust models that enable more equitable outcomes.

Want a model that doesn’t demean or patronize or objectify people with disabilities? Make sure content about disability, authored by people with a range of disabilities is well-represented in the training data.

Want a model that doesn’t use ableist language? Use existing data sets to build a filter that can intercept and remediate ableist language before it reaches an end user.

Want a coding co-pilot that gives you accessible recommendations from the jump? Train it on code that is known to be accessible.

I have no doubt that AI can and will harm people… today, tomorrow, and well into the future. However, I also believe that we can acknowledge that and, with an eye towards accessibility (and, more broadly, inclusion), make thoughtful, considerate, intentional changes in our approaches to AI that will reduce harm over time as well. Today, tomorrow, and well into the future.

• Pro: No waste to clean up & dispose of
• Pro: Can be used by people with allergies
• Pro: Has no mouth, will never bite
• Pro: People are less likely to try to pet/distract your service robot
• Pro: Can likely be trained (or sensor-enabled) to recognize more objects and scenarios than a dog can (or at least the specific breeds we employ as service animals)
• Pro: Would be of service for someone’s lifetime (and beyond) if maintained properly
• Pro: Knowledge & personality (if there is one) can be migrated to a new robot if the current one breaks
• Questionable: Potentially less costly to own, assuming power & maintenance is less than the US$1000-2000/yr it costs to own the average dog
• Con: Far more expensive upfront
• Con: Unlikely to be a companion in nearly the same way (though robots with personality is something folks are working on)
• Con: Not warm or furry

https://www.youtube.com/watch?v=1av9EnmZWNk

In the 21st century, more and more information is “born digital” and will stay that way, prone to decay or disappearance as servers, software, Web technologies, and computer languages break down. The task of internet archivists has developed a significance far beyond what anyone could have imagined in 2001, when the Internet Archive first cranked up the Wayback Machine and began collecting Web pages…

This is my son Oscar. In case you can’t see the picture, he looks nothing like me because he’s adopted. He’s also friggin’ adorable, but that’s not why I’m writing this. I’m writing this because my son is Black and despite the fact that he will grow up in a family that has the means to provide him with a good education and far more opportunity than a lot of children in America—including me—the sheer fact that his skin is dark means he will grow up in a far different America than I did.

He will be suspected when he enters a store. He will be treated differently in school. He will be policed differently. If he commits a crime, he will be six times more likely to be incarcerated than his white friends in daycare; and if it’s a drug offense, he’ll be ten times more likely to serve time.

He will be feared by default. He will be suspected by default. He will be guilty by default. All because he’s Black.

I don’t want him to grow up in an America where he could have his life ended during a traffic stop for a broken tail light. I listened to Diamond Reynolds’ recording of Philando Castile dying and I had to stop the car and cry; I couldn’t bear to watch the video. He was someone else’s son. Someone else’s little boy.

This is not the America I want Oscar to grow up in and we have an opportunity to change it. I fully recognize that the societal issues that underly the way we (as a nation) treat the Black community and other people of color in the U.S. are not new, nor are they going to go away overnight. It’s going to take time and commitment to making it happen.

What I also know, however, is that electing a president who proposes racist policies, uses racist rhetoric, and gins up racial tensions among his supporters is not going to make America a safer place for Oscar to grow up. A man who routinely derides and demonizes immigrant populations of varying shades (despite marrying numerous immigrants himself) is not going to lead us to be a more inclusive nation. And a man who has a history of treating the Black community unfairly is not going to be the champion we need to help unify our different racial and ethnic communities into that melting pot of ideas and cultures we’ve been taught is America’s greatest strength.

When I go to the polls this Fall to help my country choose its next leader, I will be thinking of my son and all of the other children in this great nation of ours. I will think about the future America they stand to inherit and I will vote against Donald Trump. I hope you will join me in taking a stand against fear, against further segregation of our society, and against racism. America is already great, and it will be much better without Trump.

The esteemed Jeffrey Zeldman kicked the day off with a talk entitled Designing with Web Standards in 2016. A theme he touched on repeatedly was that none of the problems we are facing in web design today are new problems. It’s a topic near and dear to my heart, something I wrote about in the closing chapter of Adaptive Web Design’s Second Edition and recently spoke about at EnhanceConf in London. He knocked this one out of the park and my head was nodding so much my neck began to hurt.

Next up was my former WaSP colleagueRachel Andrew to give us the skinny on CSS Grid Layouts. This is an amazing spec that I’ve always struggled to understand fully (despite the fact that’s i’ve written a Javascript polyfill for it). Rachel made it crystal clear and got me very excited about the future of layout on the Web.

Jen Simmons dropped some serious CSS-related design knowledge bombs that perfectly complimented Rachel’s talk. She discussed Flexbox, CSS Shapes, Multi-column layout, viewport units and more, demonstrating how they can be used right now to progressively enhance the design of your sites.

After lunch, Brad Frost took to the stage to talk about Style Guides. I only caught the last half—I’ll admit to doing some last-minute rehearsing in the hallway—but the bits I did catch were good. I’ve seen his Atomic Design talk a few times, which this one builds on. In this talk he touches on a lot of the atomic design concepts, but he also talked a lot more about workflow and the role of the front-end developer. No doubt the evolution of this talk has come in large part through writing a book on Atomic Design and in hosting a podcast with Anna Debenham on website style guides.

Next, I was given the opportunity to share some thoughts and advice on designing and building. My talk, The Features of Highly Effective Forms, evolved out of several earlier talks on building forms. With this one, I wanted to strike a little more balance between the nuts and bolts of building forms and the hows and whys of building better forms.

The deck, which I’ve posted to SlideShare, doesn’t stand on its own quite as well as some of my other forms decks simply because the talk contained a lot of storytelling I chose not to pair with slides—instead opting for an black screen so folks could focus—but I did call out the salient points. I’ve begun writing up some of the recommendations as part of my Modern Web Forms Best Practices series and will continue to do so in the future. And one of the stories I told, which I highly recommend you check out, had to do with a lesson Facebook learned in managing how users report offensive photos.

Josh Clark wrapped the day up with a discussion of the future of interface as things move from digital back to physical. He talked about a lot of really cool new tech that has me excited about the future, including the Physical Web, which Josh had running as a live demo. I wonder if anyone noticed I had a beacon running too ;-)

All in all, day one was a blast. As always, Jeffrey, Eric, Toby, and Marci do an awesome job programming their events. I’m really bummed I could not stick around to see Val, Jason, Krystal, Eric, Kristina, and Cameron rock it out though. I’m sure it was amazing.

You can check out attendees thoughts from the event by searching Twitter using the #aeansh hashtag.

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.

When I was mid-way through writing the Second Edition of Adaptive Web Design, I realized that it was pretty likely some of the links I was referencing might disappear over the years. Little did I know, some of them would disappear while I was writing the book!

The Internet Archive’s Wayback Machine is pretty good, but it doesn’t archive everything, and I often find captured pages end up broken—especially if they rely heavily JavaScript, but often images go missing as well. I wanted to make sure that when you pick up the book a year from now or even 10 years from now, the links will still work.

I evaluated a few options for creating a permanent archive of each and every link in the book (there are over 200), but then it dawned on me that Perma.cc might be the perfect answer.

Perma.cc was created by the Harvard Library Innovation Lab in reaction to the paper I mentioned earlier. It is a distributed archive of URLs for scholarly and legal documents, supported not only by Harvard, but over 90 (and counting!) libraries, distributed all over the world. It’s also open source. Each URL is preserved as a live view, an archived view, and a screen capture taken when the link is added. Archived URLs are kept for a minumum of 2 years, but may be “vested” into the permanent archive by a member organization.

I had contributed some CSS to the project a while back, so I reached out to my contacts to see if they might be interested in vesting all of the links for the book. Turns out they were big fans of the First Edition and enthusiastically offered their support.

Converting all of the links took time (and a lot of double- and triple-checking), but the result is that every article, blog post, and web page that I referenced in the book will remain accessible to you in perpetuity. I think that’s pretty awesome. And, as an added bonus, since Perma.cc creates unique URLs that are relatively short, those of you who read it in print won’t have to re-type the often incredibly-lengthy original URLs.

I can’t thank Matt Phillips, Adam Ziegler, Jack Cushman, and everyone else at the Harvard Library Innovation Lab enough for creating Perma.ccand for offering their service to my readers. You all are amazing!

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.

What are they planning? If its present growth and expansion continues, will Google be subject to anti-trust legislation or will it claim it isn’t because it is simply aggregating content?

The only thing I know for sure is that Google-rage is going to grow.