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.
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.
Couldn’t have said it better myself. But here’s a point:
Accessible apps (web and native) are products of great engineering.
You can’t build tool/framework your way into this type of product. It requires you to do things outside the cubicle or the stand-up desk. In some ways, you have to grow up – not just in maturity but just stepping out into the world and examining it. Realize that what you are building isn’t just for you or the lowest common denominator, it’s for everyone.
Agreed. It’s certainly easier if everyone involved – from design to development – has regular interaction with real users, of all ages and abilities. It would be great if more frameworks came with accessible components, though I admit that I have little knowledge of the frameworks out there.
Anne – I know that WordPress (CMS) and Bootstrap (framework) are working on accessibility issues. There are people more experienced than me that can talk about these two. But the funny thing is that the most simple, basic solutions are the ones that make it easier for accessibility. Once the basics are down, accessibility is simple a by-product.
Thank you for writing this.
Almost every presentation I’ve given on web accessibility starts the same way. I also pull points from Sara Hendren’s article “All technology is assistive technology”. A good read if you’ve never read it. More specifically, I reframe for people by pushing towards universal design.
I definitely like the matrix idea as a practical way of doing a checklist.
Well written especially the personas part. I am learning to identify personas for my projects and this adds a perspective towards how should the identification should be approached.
@Vatsal – I’m actually having a lot of fun slipping “accessibility issues” into my existing project personas. It’s causing a lot of double-takes among the business contacts, but nobody’s objected. (A few have asked, “Why?” and I’ve replied “So we don’t forget to test it.”)
Um, Anne, if you’re going to talk about ‘people’ why dont you discuss testing your interface on real people? Matrix theory and personas are no substitute for talking to real end users 🙂
Good question! Two reasons.
First, I worked off the assumption that we’re already usability testing our products with real live humans on a regular basis. Jared Spool and UIE established as early as 2011 that regular exposure to usability testsincreases the success of UX teams on a regular basis. If that’s not happening in a team’s organization, it probably needs to be fixed first.
(There may also be challenges in recruiting users that specifically have accessibility difficulties depending on your recruiting practices. These are especially complicated if you’re working on an intranet and Human Resources is involved.)
Second, because I’m targeting the unit, integration, System Acceptance, and Client Acceptance testing that takes place on any system before we put it in front of users, even for usability testing. Just as I wouldn’t expect a user to complete a usability test if the page wouldn’t load or the mouse didn’t work, I don’t expect a user to complete a usability test when a screen reader doesn’t work or the speakers aren’t plugged in.
It’s not the responsibility of the user — at either the usability test or in production — to uncover the obvious flaws in the user interface. We need to make sure we’re providing basic functionality before we ask the user if it’s usable.
So usability testing should absolutely occur – after you make sure your software works at the fundamental levels. Hopefully this guide will help you get to that step.
Yes, accessibility is incredibly important.
No, I don’t think ALA is the place to discuss people with disabilities, stereotypes and political correctness.
Your article is highly ideological (“Why do we fixate on justifying the existence of people with disabilities?”) and p.c. which distracts from the important technological and work ethical things you write. It’s not the first “political” article in recent months and I really, really hope editors focus on what ALA is about in future entries. No hard feeling please, Anne. Just my opinion.
Wow, this is a really interesting and thought-provoking article. My initial response to your conclusion was, “yeah, that’s a really good way of looking at it”.
But then something started to bother me, and it’s kind of hard to articulate, so bear with me 🙂
When I first started to advocate web accessibility, I tried to frame it in universal terms — accessibility is about everyone, and everything we think of as an accessibility requirement has benefits for more than one user group. For example, I would say that single-column layouts are useful for people who use very large text or screen magnifiers, and that they’re also better for viewing on mobile devices. So an accessibility requirement is framed in terms of accessibility + added benefits, and that makes it easier to sell, harder to dispute the importance of.
But the effect of that approach was actually the reverse. Instead of promoting accessibility, I was giving people an excuse to ignore it. Because, “oh we’re not concerned about mobile devices, so we don’t need to do that”.
Ultimately, I came to the conclusion that framing accessibility in terms of everyone is actually a distraction, because that isn’t really what accessibility is about. Accessibility is about providing for the needs of people with disabilities. Accessibility is positive discrimination.
After all, we are not legally or morally obliged to make a site work for tablets, or mobiles, or any particular voluntary preference. But we are legally and morally obliged to make the site work for people who are blind, or deaf, or have a mobility or cognitive impairment (among other things). Such impairments do exist within a spectrum — I completely agree with that; there is no such thing as a “normal” human being. Nevertheless, there is a specific evolutionary basis for what we consider “disability”, and the WCAG specifications (and the law) must frame accessibility in those terms.
That’s the original conclusion I came to, anyway. But I keep wavering between that and my original point of view, and your article has made me stop and think about it all again 🙂 I’ll be interested to know what you think; whether there’s a way of resolving this apparent conflict of intentions.
And yet this webpage is not navigable by keyboard (tab) and images are missing alt=”” entries. The sentiment is great but Anne should help this website become more accessible.
@listapartfan No site is perfect with regard to accessibility but the key is whether issues that are identified get addressed. I tried to navigate the site with the keyboard alone and am able to (although I have a few comments about making the tab order better and a couple of other items). I also reviewed this article page and am not finding images that are missing alt=”” where needed. Can you help by pointing out the issues in more detail so they can be reviewed?
Anne, this article is a bold and important statement. Thank you for writing it. The line that struck me the most is:
Just as web developers first conceptualized responsive design as mobile support, so too have we introduced accessibility as disability support. The analogy tells us that our understanding of accessibility will broaden and deepen as the techniques to support it become embedded in the structures of our tools and process. Eventually we will all understand the accessibility is the basis of interface design and development — as web professionals we make information accessible to humans and machines (yes machines, too!).
There are numerous open source projects attempting to address the development of consistent accessible user interfaces. I believe that automated testing is an important component of this effort and it’s why I devote time to developing Quail (https://github.com/quailjs/quail). If this is something you (and I mean anyone reading this comment) would like to support, consider contributing to the project!
@James Edwards
You’ve got an interesting problem there. I’m sure the example that you use — framing accessibility as useful in terms of mobility, only to have mobility rejected as not useful — wasn’t your only attempt, but it does point to a problem we have in communicating the importance of accessibility: we have to attach the value of accessibility to something our clients already care about. There isn’t a universal way to frame accessibility that will work for all clients and all audiences. In fact, if we have to “sell” accessibility to our clients, we may need to change techniques multiple times during the same project. My hope is that the web design and development community can shed this need to “justify” accessibility by no longer listing it as a line item in a quote or a proposal. If we’re just doing it, if testing a screen reader is as automatic as testing a keyboard, then hopefully we’ll set the standard to our clients that it must be done. But that means we have to change our mindset as a community first. That’s my goal.
@J. Renée Beach – Thank you! I’ve seen a couple of automated testing suites and I’m hoping they continue to improve. Thanks for working on better tools for all of us!
Hi Anne,
I found your comments about changing the way we discuss and consider ‘differently-abled’ people or technology users to be inspirational. What I am struggling with are the cost dynamics of building and testing websites for everyone.
I agree with James’ comments that we are morally (even legally, in some cases) obligated to build sites that work for those with disabilities but the primary reason our clients don’t do so is cost.
Even if we could build fully accessible sites or online applications without added cost (ftr, we can’t) the act of testing them on the variety of devices is time-consuming and costly. Where this usually leaves us is building a site using basic best practices for Level 1 of the WCAG accessibility guidelines (http://www.w3.org/TR/WCAG10/full-checklist.html) and hoping for the best. In other words, building the site to be universally accessible falls by the wayside along with supporting IE7 or other browser/OS combinations that make up less than 5% of traffic to the site.
Any thoughts on how to make this kind of priority affordable for clients who are essentially at their budget limit getting a site designed and built that works with modern browsers across desktop and mobile devices?
Hi @percasey!
First, a disclaimer: my background is primarily in enterprise UX (building for either intranets or for the customers of the financial company where I work) so if anything sounds particularly odd from the agency or indie standpoint, my apologies.
Level 1 is a good start, and if all your sites are 100% complaint with Level 1 you’re probably ahead of most of your competitors, and thus your clients are ahead of their competitors. They may even be able to use it as a marketing tool. But I’m struggling with the rest just as you are. I think the key is to stop making it optional.
To use a very tenuous analogy, ten years ago back-up cameras in cars, if they existed at all, would have been an expensive optional feature. Today they’re part of the base model. (Tomorrow they’re the law.) What happened during those 10 years? The price of a back-up camera went down, sure, but it didn’t disappear. Customers began to expect it, manufacturers caught on, and the price of the base model went up to compensate.
Today, accessibility is treated like an expensive optional feature, when it should be a standard feature. As an industry, we already moved “support more than one browser” and “support for mobile” into the base model. Those were both expensive features, but they were required by our customers. Accessibility should be required by our customers, but even if it isn’t right now, I’m betting that at least in the US it will soon be required by the law. We might as well be ahead of the game and put it in the base model.
As for the cost, well, the most expensive time to deliver a product that requires a new skill is going to be the first time we use it. The first time we switch to a new language, a new library, or a new methodology, there are lessons to learn and kinks to work out. (In my experience we don’t usually line-item charge clients for those changes, even though they make us less efficient. “There’s a 10% increase in costs because we’ve decided to learn Angular.”) But a few weeks or months in, we learn a lot — and we start building a library of working code (or design patterns) of our own. We can then leverage what we’ve learned to lower the cost of accessibility in the next project. That continues until a) we know enough about what we’re doing that it’s only a 2% increase in costs instead of a 20% increase, and b) we don’t even consider not doing it because it’s the right thing to do and nobody’s going to argue with 2%. To get there, we need to start.
Love this article Anne, thank you!
By happy coincidence Isolde Carmody has written a brilliant and funny/tragic piece on the same topic from a user’s perspective her: https://accessadventures.WordPress.com
Well written article. Although I agree with most of the article, there’s a couple of things where we should see a different standpoint when thinking accessibility and business.
“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.”
Let’s imagine a situation where we are optimizing a website of our company. We have a few things what we can do, improve our website SEO and get more visitors, or improve our website accessibility. It’s very likely that we are going to earn more money through our website by SEO than having a better accessibility in it.
Most of the companies out there are aiming to succeed in a business world, aka. to make money as much as possible, it’s just a cold fact.
But you are right, we SHOULD value accessibility over “there aren’t enough of “them” to make it worthwhile” thinking, it’s morally right thing to do.
Things which are more profitable when done, are more likely to be done. We people are greedy.
Hi Anne,
The web accessibility policy in the Netherlands is based on what you describe in your article. The right of access to on-line information and services is not limited to people with disabilities.
The current Dutch web accessibility standard Web Guidelines version 2 fully incorporates WCAG 2.0, without alterations or deformities. But besides Perceivable, Operable, Understandable and Robust it contains one more principle: Universal. The guidelines under this principle are about [1] the semantics of web technologies that are used (example: don’t use tables for layout purposes), [2] strict separation of content, style and behaviour (a precondition for responsive design), [3] layered construction (example: progressive enhancement), [4] meaningful error messages, [5] usability of forms, [6] multilingualism, [7] nested viewports (example: frames), [8] character encoding (UTF-8 is mandatory), [9] use of open, vendor independent specifications, and [10] sustainability of URI’s.
So I’m with you about the need for reframing web accessibility. But I don’t agree that reframing accessibility as a technology challenge solves that problem. Web accessibility is not only the domain of web workers, who (are supposed to) understand the technological aspects of the subject. Policy makers, executive officers and supervisors also have a role in this matter. They are are insufficiently reached when the reframing is limited to the technological aspects. Even worse, reframing accessibility as a technology challenge fails to address the problem that these actors not always take up their role, because web accessibility is ‘just’ a technological problem, not a managerial one. Don’t get me wrong though: what you describe does contribute to solving the web accessibility challenge. But more is needed.
Web accessibility policies worldwide are based on conformance with specifications such as WCAG 2.0. The effectiveness of such policies is evaluated by testing websites against the spec. In case of WCAG 2.0, it is explicitly described when conformance can be claimed: all success criteria of a given conformance level must be met in full. This means that, without deviating from the norm, evaluation of adoption can only be based on three possible outcomes (excluding level AAA): [1] a website owner can successfully claim conformance to WCAG 2.0, level AA, [2] a website owner can successfully claim conformance to WCAG 2.0, level A, or [3] a website owner can not successfully claim conformance. Experience has shown that the most likely outcome is 3, hence policies that are directly linked to WCAG 2.0 conformance are bound to fail.
What is needed is a better insight in the reasons why, in cases where conformance cannot be claimed. That’s in most cases… Test results alone do not provide this type of information.
A couple of weeks ago, I tweeted a figure about the subject, in which a new approach is introduced. The proposed approach uses conformance testing, but also takes into account the external influences that may prevent website owners from successfully claiming conformance. The figure is used in a paper that was submitted for the Web4All conference in May.
(If you’d like to receive a copy of the paper for review purposes, please let me know.)
Hi Anne
Thank you for an interesting article. I second many of Raph’s points above. In particular I strongly disagree that ‘Accessibility is a trait of the website itself’. This suggests that accessibility is unchanging, that our knowledge of what is necessary to achieve accessible websites and experiences is complete, and that web resources stand alone, independent of context (or even framing technologies beyond a developers control). Clearly there are many positive steps that designers and developers can take to ensure their sites are more inclusive – however, accessibility is relational, dependent on the development/content side, but also the user’s actions in a given context. Much of this is also dependent on how disability is understood (an element that your article refers to), and this can be very culturally dependent. In short, web accessibility is not an intrinsic characteristic of a digital resource. It is determined by complex political, social and other contextual factors, as well as technical aspects which are the focus of WAI standardisation activities. There’s a lot to say here – and lots of positive steps (beyond WCAG, or a matrix focused on Assistive Technologies) that developers can take to attend more closely to context, experience and interaction.
Some open access (academic) papers that go into this more deeply, are:
Developing Countries; Developing Experiences: Approaches to Accessibility for the Real World (2010)
A Challenge to Web Accessibility Metrics and Guidelines: Putting People and Processes First (2012)
Bring Your Own Policy: Why Accessibility Standards Need to be Contextually Aware (2013)
Thought provoking article. I liked James – ‘positive discrimination’ comment. However, framing the entire ‘accessibility project’ around some vague politically correct notion of addressing the needs of ‘the people’ would result in absolutely nothing getting done that worked effectively.
Anne, thank you for this interesting and provocative article. You make many important points and have sparked some great discussion. In my estimation there’s a problem with your opening remark:
I believe web accessibility must be about making sure people with disabilities can use the web — positive discrimination, as James says, to ensure the needs and preferences of people with disabilities are considered when we create technologies, designs, products, and services.
We need the official W3C definition of accessibility in order to make sure the needs of people with disabilities are front of mind in all our efforts.
I do think user experience is about making sure people can use the web, and when we incorporate accessibility into user experience activities, that’s the context in which accessibility is about “people are people.” I believe that’s the point you are trying to make, but it gets lost a bit in translation.
Hello Sarah,
In my experience, reserving the term accessibility solely for the benefit of Individuals with Disabilities (IWD), is that it influences cognitive dissonance surrounding how best to define it. For example, it’s not unusual to hear a claim of needing to design for accessibility, then clarify that doing so will allow blind people to access their content. Eventually people get stuck in their reasoning for making a site accessible, which exacerbates the stereotypes of the people who will benefit from it. When people challenge the accessibility of that implementation, the content owners defend the design as conforming to the needs of their definition of disability.
Merriam Webster defines accessibility as “providing access, capable of being reached; communicated or deal[t] with; influenced or; being used.” It means capable, which is a quality as defined in your book A Web for Everyone:
— A Web for Everyone, by Sarah Horton & Whitney Quesenbery
In my opinion, accessibility should be defined as the quality of UX that places people first, regardless of their level of ability. The minute that you make the claim that accessibility only benefits IWD, you make decisions about which quality sets a user apart from the core demographic. Once we make decisions regarding what exactly makes up a disability, we end up losing track of the 9 principles of an Accessible User Experience Framework detailed in that book. In doing so, we end up discriminating against others who fall outside our interpretation of disability.
I suspect that if the original authors of the Web Content Accessibility Guidelines had kept the definition to refer to everyone, it might have been written in such a way that doesn’t alienate other disabilities who require AAA criteria.
Jonathan, you rascal! Using my words against me. 🙂 I agree 100% that accessibility is a quality attribute of user experience, and people first FTW!
I think the W3C definition of accessibility focuses attention on the needs of people with disabilities, to ensure those needs are on the table when we are creating technology specifications, development frameworks, browser features and functionality, assistive technologies, digital products and services. Unfortunately, I don’t think our approach to accessibility is mature enough at this time that we can lessen that focus.
As we integrate accessibility into user experience, my hope is that we drop “accessible” and just talk about user experience. I believe that’s what Anne and all of us are after, and I believe that’s where we are headed.
How is it unreasonable for people to look at the number of users affected by an issue? This site and the author’s site look really bad and are hard to read in IE5. Without looking at numbers it is impossible to tell how big of a problem lack of IE5 support actually is.
In my opinion, the ideological tone of accessibility articles such as this serves more to alienate web devs than it does to encourage them to make sites more accessible. Let’s make some allowances for pragmatism when we discuss these issues.
Is it really immoral to have a site that’s not 100% accessible? Many commenters have taken this view but I don’t think it stands up to scrutiny. The tables in this article are images. Do we really want to impugn the author’s character because of that?
Raph, you wrote
Yes. I agree. This article isn’t intended to set the universal policy for accessibility, and if I made it sound that way, my apologies. Policies in particular should be about people with disabilities, concentrating on the people and process more than the technology.
You also mentioned
My experience is that website owners can’t claim conformance because they or their developers did not value accessibility conformance as something to strive for. Those are the people to whom I think we need to provide a new framework: one where “accessible” is just another aspect of “good code” and “standard business”.
Sarah Lewthwaite wrote
Wow, that’s certainly not what I intended to imply. Nothing about a website is unchanging, from the experience to the knowledge, to the content, to the design, to the back-end and front-end. And I agree that accessibility isn’t mature. But I can’t say “This website is accessible” without implying that accessibility is a trait of the website. Accessibility does not mean the user, it means the software, hardware and I/O, in whatever state of maturity they’re in.
All of those other aspects you mention, cultural, political, social, and contextual dynamics, as well as the user’s immediate needs and context, I agree are the bigger picture of accessibility.
Sarah,
For what it’s worth, I thought the book was awesome enough to merit a proper nod!
Thanks for the clarification. I agree with your assessment as to why the W3C defined accessibility in that way, but I don’t agree that it was the best direction to go. Politically speaking, specifying disabled users in a definition makes the most sense when highlighting the importance of creating accessible sites. However, as the W3C has been identified as the de facto authority for web standards, it ended up redefining a term that others are now quoting. Because of this, I suspect it will be very difficult to “drop ‘accessible'” as accessibility becomes more integrated into user experience.
In my opinion, this stage in our ‘maturity’ is the best time to revisit how accessibility specialists market and promote accessibility. Many companies continue to integrate accessibility into their workflow only after that need becomes apparent. I see this in organizations who have already achieved high maturity levels of CMMI and embraced Agile and Lean project management methodology. I believe they continue to operate this way because the definition of accessibility relies too heavily on defining a type of person. Products are only developed if they meet the needs of a wide demographic, but asserting a quality as beneficial to one type of person means they will often be overlooked. Anne makes a brilliant observation that IWD are a “subset of those primary customers.” Unfortunately, until we decide it’s okay to wrap IWD into the greater audience, it will continue to prove challenging to help others decide when to include it a workflow.
To address the concern of potentially ignoring the distinct needs of people with disabilities, projects and processes would benefit from acknowledging which requirements are necessary in order to access their content. Effective Project Management requires elicitation to determine those requirements that are not known. Integrated testing would ensure needs are met. If content providers and developers integrated design and accessibility into their project management, inclusive design would become the requirement. Once ‘designing for all’ becomes the requirement for project management and organizational policy, ensuring accessibility will mean products are developed for the widest demographic. People with disabilities would cease to become an afterthought because now they are included as primary customers.
Hi all. I was reading through this really interesting conversation when I saw A Web for Everyone mentioned. (Thanks) Let me try a slightly different take on “everyone” vs. “people with disabilities.” In the book (and through the title), we took the position that doing good design and coding better is an important part of accessibility. We choose colors. Why not choose colors with enough contrast? We have headings in our text. Why not mark them up correctly? And so on. This is better UX because it lets more people have a better experience. The same thing that lets me make the text a little bit bigger can let someone else make it a lot bigger. But the thing that trips us up is that there are some things that we must do, no matter what. That’s because they remove absolute barriers. If I don’t describe an image, someone who can’t see it has no idea whether it communicates something important or is a decorative doodle. And, if the widget to select the size of a shirt on an ecommerce site isn’t coded properly for keyboard or a screen reader, it doesn’t matter how wonderful the rest of the page is: I’m not buying that shirt. We need to avoid creating those absolute barriers. And we also need to create the habits in our work (whether we design, research, write, or build) that make the web a better place for everyone.
I believe in the idea of universal design, i.e., that a website can meet the needs of all users, and think we can eventually come close to achieving it. We are quite a ways away, however; for example, to truly meet the need of all users, a website would have to adapt to differences in learning styles and cognition, which websites certainly don’t. It’s difficult enough to ensure websites meet WCAG 2.0 AA guidelines much less building them to be adaptive.
Another issue is the decreasing, but still significant, lack of awareness about the need for accessible design. Designing websites so they are accessible for persons with disabilities is not a given; there are still plenty of sites that persons with disabilities can’t use.
For those reasons my perspective is that it’s still productive to speak of designing websites that accommodate the needs of persons with disabilities, since it provides a necessary and useful focus that might otherwise be overlooked.
I thought some might be interested to read further discussions of this article taking place both on the WebAIM email list, as well as the WAI Interest Group list.
The start of the thread on WAI-IG is:
http://lists.w3.org/Archives/Public/w3c-wai-ig/2015JanMar/0093.html
And the WebAIM thread:
http://webaim.org/discussion/mail_thread?thread=6769
Kudos to you, Anne. It’s great that you’ve opened such valuable discussions. Thank you for working for change.
Thanks for pointing those out, Jennifer! I have to admit I didn’t expect to rattle cages that high up in the world. Then again, it’s no accident that “general troublemaker” is in my bio.
Over in the WebAIM thread Tim Harshbarger sums up what I was aiming for in this article better than I think I managed to:
Thank you to everyone for the great thoughtful comments and the clarifications and debate. The most valuable thing about being an author (for me) is what I learn from those who interact with the work.
`Hi all!
I live in Belgium – Europe and I have ALS, which means in my case that I cannot breathe, speak or move (not even a finger or a toe).
I am so glad I found this site!
My computer goes online and I buy everything online!
Somewhere (online) is an article that says that 1 in 50 people is in a wheelchair.
And what do we do online?
Right!
Buy stuff!
Something to think about…
Schanulleke
Anne, I appreciate both your article and your responses to the comments on the article. I’ve found myself reading this article multiple times and spending time reflecting on points you made in it. I hope you will write more articles in the future.
The stair case.
Worth mentioning Addy Osmani’s a11y audit tool: https://github.com/addyosmani/a11y/
Even as the discussions have continued, on both lists, I thought I’d note a couple of articles that I saw being circulated. Here’s
The role of accessibility in a universal web:
http://dspace.mit.edu/handle/1721.1/88013
And also this, from the W3C’s Web Accessibility Initiative —
Designing for Inclusion:
http://www.w3.org/WAI/users/
Although the article gives plenty of practical guidance for assuring accessibility, there are a few aspects which in my opinion point in the wrong direction. After writing down my thoughts, it seems better to post it on my blog. It is longish: http://www.chemnitzer-14.de/accessibility-is-usability-in-context-of-disability/
Nevertheless, thanks for the excellent work.
As the discussion continues beyond this post, here’s an article, translated from German, and posted to the WAI-IG email list:
Accessibility is usability in context of disability
http://www.chemnitzer-14.de/accessibility-is-usability-in-context-of-disability/
Just trying to leave some kind of cross-posted record . . .
And I see Jan has already posted this. Thanks!
I’d delete duplication, but I don’t see a way to do so.
Really good to see this article as I think UX as a practice cannot move forward if we constantly ignore this aspect of it.
I really like the comment by Ville Rouhiainen because in my thoughts around this, it is crystal clear how our society and tech now, generally caters to the wealthy. I’m also from a ‘developing’ country so I know the effects. I’ve written about how discrimination based on wealth is acceptable (first class/Upper class ?), and this seeps in into many aspects of our lives including accessibility.
“Let’s imagine a situation where we are optimizing a website of our company. We have a few things what we can do, improve our website SEO and get more visitors, or improve our website accessibility. It’s very likely that we are going to earn more money through our website by SEO than having a better accessibility in it. Most of the companies out there are aiming to succeed in a business world, aka. to make money as much as possible, it’s just a cold fact. But you are right, we SHOULD value accessibility over “there aren’t enough of “them” to make it worthwhile” thinking, it’s morally right thing to do. Things which are more profitable when done, are more likely to be done. We people are greedy”
Until we start to see ourselves all on the disability spectrum (as you mentioned), we will not be able to but design for those most similar to us and this involves a re-education on who ‘users’ are.
A good read on this ( Money vs Accessibility )is the recent development by Flipboard http://christianheilmann.com/2015/02/15/flipboard-and-the-mobile-web-dream/
This is a really fantastic article. I especially love how you comment on our currently flawed default thinking about “designing for accessibility.”
Accessibility is a trait of the website itself. <-- this really spoke to me. Yes, I completely agree. Accessibility is core in making our content functional and useful. It shouldn't be an "enhancement." If anything, fancy visuals are an enhancement to content. I loved your statement that "accessibility isn’t about defining your audience and building to their needs."
Andrew, I suspect the comment regarding images is that the two very important matrix tables are just images. Yeah, they have ALT text, but obviously a couple of words about the table is not equivalent to being able to consume the tables. It’s a somewhat unfortunate occurrence in an article taking others to task for not making things accessible. Glass houses, and all that.
[removed][removed]
Accessibility is certainly a distraction, it is to fulfill the needs of the disabled, affirmative action, as we are required to do work for people with some added to that which anyone for their condition may experience difficulty easier.
messages and articles about accessibility often fail in some cases because they are often written to a one-size fits all audience. I’ve found the theme “the web is for everyone” resonates with folks new to accessibility, but is lacking when the designer and developers are trying to make responsive web work for everyone and meet the 3 break points.
In other words there is a better time for inspiration articles, a time for practical guidance for a designer, and another time for practical advice for a developer – the three are related, but different and adapted to the role of the reader, the time in the project life cycle (arch, design, code, test, or maintenance), and the expertise and maturity of the project – e.g. are we just starting or is this a tweak?
Who needs to change the way they talk about accessibility, when, and to whom?
great thing that you share this article…
Great perspective and insight, thanks!