We need to change the way we talk about accessibility. Most people are taught that “web accessibility means that people with disabilities can use the Web”—the official definition from the W3C. This is wrong. Web accessibility means that people can use the web.
Article Continues Below
Not “people with disabilities.” Not “blind people and deaf people.” Not “people who have cognitive disabilities” or “men who are color blind” or “people with motor disabilities.” People. People who are using the web. People who are using what you’re building.
We need to stop invoking the internal stereotypes we have about who is disabled.
We need to recognize that it is none of our business why our audience is using the web the way they’re using it.
We can reframe accessibility in terms of what we provide, not what other people lack. When we treat all of our users as whole people, regardless of their abilities, then we are able to approach accessibility as just another solvable—valuable—technical challenge to overcome.
Who are these “people with disabilities,” anyway?#section2
Let’s talk about stereotypes and prejudices.
First, we need to acknowledge that most of us have a bias blind spot. Even if we think we don’t have stereotypes about “people with disabilities,” there’s a good chance that we do and just don’t realize it. (If you don’t, great for you! Play along anyway.)
By definition, a stereotype is “a widely held but fixed and oversimplified image or idea of a particular type of person or thing.” Negative stereotypes of people with disabilities are common, and are a symptom of ableism: the belief that able-bodied people are the norm, and that people with disabilities should either strive to “be normal” or keep their distance.
A blogger who goes by the name “Bookwormblues” describes this phenomenon in the essay, “I am not broken: the language of disability.”
We seem to live in a world where the able-bodied among us are considered normal, and everyone else must strive to attain that level. That thinking floods the books we read, the way we view others, how we talk to each other, and the words we use. This mindset sets a ridiculous bar for people who, for whatever reason, might require an atypical way to get from point A to point B. The thing about ableism is that it’s everywhere, and it’s incredibly common, and we don’t even realize it.
Let’s look at the language we use to describe people who need accessible websites.
A number of influential websites, including WebAIM and Wikipedia, begin their discussions of accessibility issues with a categorized list of disabilities we need to develop for: visual, auditory, physical, speech, cognitive, and neurological. Granted, if you have no experience with what accessibility means or who it affects, this is a good starting point. Still, we need to recognize that we start our accessibility conversations by categorizing the ways “they” are not “us.”
When we hold a prejudicial view toward a group we are not members of, we tend to see “them” as more alike than the groups we are in. In other words, we see the groups that “we” belong to as full of diverse individuals, but “they” are all alike. This is called out-group homogeneity.
We have simplified the out-group of “people with disabilities” in terms of long-term, severe, life-altering circumstances. We tend to think of them as having obvious outward cues: the white cane and glasses of the blind, the wheelchair for the motor-impaired, the altered speech and huge hearing aids for the deaf. The long-suffering family members standing by, caretaking. The “superhuman” inspiration of a successful person with a disability.
This is wrong, too.
I can think of at least 26 ways to define a need for accessibility, many of which are invisible, temporary, or off the usual radar of accessibility scenarios.
WebAIM discusses a phenomenon where a large group of people are asked if any of them have a visual disability. Very few audience members say that they do, even when a sizable number of them wear glasses or contacts. Despite the fact that they (and I) wear assistive technology to see, we don’t see ourselves as “people with a disability.”
It may be more effective to see our differing levels of ability as a spectrum instead of a setting. There are people who will always self-identify as having a disability. There are other people who will never see themselves as disabled, despite needing accessibility technology such as glasses, canes, or track balls. In between, there are infinite combinations of needs, some of which last for mere moments, and others which last for the life of the person.
If we make the choice to consider everyone “a person on the ability spectrum” instead of separating the “able-bodied” from the “disabled,” we stop treating people with different abilities as members of an out-group, and we start treating them as part of our own diverse in-group.
Note: If you ask a large group of people with different kinds of disabilities what they want to be called, you will get a large number of answers. Some prefer “people with disabilities,” some prefer “disabled people,” some prefer their specific situation be called out, some would rather not mention it at all. For this essay, I chose “people with disabilities” because it’s what my friends call themselves. As always, you should ask a person what the prefer, and respect them by using it.
Why do we fixate on justifying the existence of people with disabilities?#section3
Tell me if you’ve heard this one before. A big web design change is about to go through, and someone on your team has just discovered a bug that will cause problems with accessibility. One of the decision-makers in charge of the budget asks, “Well, how important is it? I mean, how many blind people do we have using the site, anyway?”
I’ve had many otherwise totally reasonable people justify not spending money to repair an accessibility issue because there aren’t enough of “them” to make it worthwhile. Strangely, these same people have no issue with spending more money on “expert users” or making their applications “feature-rich,” as long as it’s done for the “primary customer”—never realizing that a subset of those primary customers are people with disabilities. As uncomfortable as it makes us feel to admit it, when we make the decision not to support people with disabilities just because it’s expensive or hard, we’re being ableist.
Our customers, our users, are all people. They all have the same customer needs—whatever those customer needs are. They all have money that spends the same way. They are all just like you, except in the ways that they are not. They all deserve equal amounts of our respect. The only difference between these groups of people is the attitude we take when serving them.
Frankly, it’s none of our damn business why someone wants your website to work without a keyboard or a mouse, or on a screen reader or a Braille output. When you walk into the local grocery store, nobody greets you at the door and tells you that the store won’t work for you because you’re wearing glasses. Neither you nor your business should expect your audience to step up and voluntarily tell you what accessible technology they use, or why, or anything about their medical history, just so you can sell them socks, or a mutual fund, or a house.
So let’s build accessible websites, and let’s talk about accessibility—but let’s talk about it in terms of feature sets and technology, not the quantity (or value) of one set of users over another. Let’s teach our business contacts and our managers and our tech leads and our Scrum masters that we’re building software for all of our users, and we’re no more going to give them a lousy experience because they have a disability than we would for their race, creed, or gender.
Reframing accessibility as a technology challenge#section4
We cannot afford to let stereotypes and prejudices alter the perceived value of our audiences. Let’s stop quantifying people and instead start quantifying experiences. Let’s justify accessibility by putting the emphasis on the technology instead of the users.
Let’s start by expanding our view of what can connect to the web. Start with hardware, the interface between the people and the bits. What might people be using? What combinations may occur? This research is as simple as building a spreadsheet.
Creating a test matrix for accessibility#section5
Here’s how to methodically build a test matrix that defines an accessibility strategy by combining accessibility scenarios with other testing types. The result is that you’ll no longer need to justify your testing of accessibility issues based on the relative size or merits of the audience any more than you justify testing different screen sizes or different browsers. This matrix makes accessibility testing one more factor in the testing you do normally.
- Read this list of input devices for computers.
- Read this list of output devices for computers.
- Create a matrix of these devices in your favorite spreadsheet format. (If you normally write your test cases in a list or other format instead of a matrix, that’s fine too! Creating the matrix and then transferring the results into your other format will probably make the transition easier.)
- Cautiously determine the likelihood that a combination exists.
- I have yet to hear of a laser rangefinder-input and plotter printer-output web-surfing technique, so that can be removed (at least until the makers read this article).
- You may be tempted to cross out that Wii Remote and TV combination, but to do so is to ignore the growing use of consoles as web devices.
- I thought mouse-input and screen reader-output didn’t make sense together and shouldn’t be in the test matrix, but then I discovered Find the Invisible Cow.
- Remember that this is not a list of what your users use today; it’s a list of what exists. If your current website is so inaccessible that screen readers don’t work, well, of course your data is going to show you have no screen reader users. You drove them off!
- Look for opportunities to combine other elements of your test cases, such as different operating systems, browsers, or screen resolutions. It’s important to cover as much ground as you can with as few test cases as possible.
- Once your matrix is set, keep it as your template, and simply make a fresh copy from this each time you run the tests on a website.
- For each application on your site, identify whether it works, doesn’t work, or wouldn’t apply, noting the results in the spreadsheet.
For example, if I were reading an article on a news site, with an accompanying video, I might see test results that look like this:
Applying the matrix to personas#section6
This method can be easily integrated into personas or Agility user stories by ensuring that at least one of every block makes it into the description of at least one of your personas.
For example, here’s a persona for a processing supervisor at a fictional pharmaceutical organization:
Harold is a Processing Manager member who has been with PharmaCo for sixteen years. He started out as a Processing Associate and worked his way up through the ranks, so he knows the roles and responsibilities of his team members as well as they do. Harold’s primary responsibility is to ensure that his team members are getting the mail queues emptied as quickly as possible. His secondary responsibility is helping his team shape their careers and move up in the company ranks, just as he did. He’s also responsible for two projects within the department, and he’s a member of the Diversity Committee.
Harold spends most of his time in meetings. His team reaches him via email or chat if they need something. One week out of every four he’s assigned to handle QA rejected items and discuss them with the affected crew members. These arrive to him through WebApp3, but he has to use WebApp2 to contact the team member affected. Because Harold is on-the-go, he uses a tablet with a touchscreen as his primary computer.
Harold began losing his vision about six years ago, but he’s not completely blind. He has the screen text on his tablet zoomed all the way up, but he’s prone to headaches if he tries to read for too long. Harold uses the screen reader built into the tablet to read him long emails or messages. He carries headphones with him so that he doesn’t disrupt other employees in his area.
The key here is that the personas are not extra “disabled people” personas, they’re personas of people with real scenarios and real needs who, coincidentally, are using the accessibility features we built into our sites. Because every persona has a hook back into the test matrix, the temptation to cut Harold from the budget is much harder to take—cutting Harold means cutting the testing for WebApp3 to WebApp2, cutting the testing for the tablet screen size, and cutting the testing for a screen reader.
Checking content against the matrix#section7
Finally, this method provides extra checks and balances against your content strategy. It simultaneously pushes your writers toward “concise, appropriate, useful content” and provides extra opportunities to review the content in multiple formats. It does so by ensuring that you view your content in different contexts—different layouts, different formats, different delivery methods. We see our content in a different light through each one. These reviews give us the opportunity to identify problems that a single review in a single location would not.
If the content doesn’t make sense when it’s heard, then it probably isn’t clear when it’s read. If the content doesn’t make sense without its images, then it may need to be rewritten or rescripted.
Testing beyond the obvious#section8
You will quickly find (as I did) that building accessible websites is more difficult than inaccessible ones. Semantic HTML, well-designed standards-compliant pages, strong information architecture, a clear content voice, a good test suite, and a thorough understanding of accessibility issues are all required to make accessible websites. Hopefully, these are all goals you’re already striving for, and increasing your site’s accessibility is just one more reason to pursue them.
Using a testing matrix and personas that include accessibility issues will also help prevent the “tunnel vision” that sometimes develops if we’re looking at only the most obvious accessibility issues. I once worked with a team to create an educational video about expenses, and we knew the videos would require transcripts to be accessible. We built the transcript, set it in the site architecture, and even added the charts and graphs from the video to the transcript so that it was easy to understand. Then, late in the project, a colorblind co-worker pointed out that he couldn’t differentiate the colors in the charts. We’d addressed the most obvious concern, and still managed to produce an inaccessible design. We’d fallen into the trap of thinking that “only the deaf” would have problems with a video.
People over process, unless process enables people#section9
Accessibility isn’t about defining your audience and building to their needs. Accessibility is a trait of the website itself. The website is either usable on this hardware and software, or it isn’t—and as I’ve shown, this is something you can build into your testing process today. If your audience can’t access the information they need on the majority of input and output combinations, then you’re failing to meet their needs.
It’s important that we center our discussions of accessibility on the hardware and software, instead of on the audiences that use that hardware and software. Our current process of defining our audiences’ needs based on their physical limitations too quickly degrades into the process of creating stereotypes, categorizing our audience members, and then deciding whose needs to satisfy based on the finances of the task.
No person should be treated like their value to your business is based on the expense of building software that uses input and output methods you didn’t think of the first time. No person should have to justify why they’re using the hardware or software that allows them to be successful.
People are people. They come in many shapes and forms and abilities. Computer interfaces are input and output hardware. They help people communicate with software. Websites are software that help people accomplish their goals, regardless of the hardware and software combination, regardless of the shapes and forms of their people. That is accessibility.
