What is it
For a product or service to be accessible, it needs to be something that isn't constrained by the myth of the average person. We make assumptions about people and how they'll interact with the things we make. Humans being a wonderfully diverse (and delightfully weird) bunch, those assumptions are going to be wrong a good chunk of the time.
If you're a developer, you'll recognize this fallacy as a cousin to "it works on my machine".
The idea that some people are "disabled" and others are "normal" isn't just insulting to people who struggle with particular health issues - it's also just plain wrong (and a terribly flawed basis for design). Everyone can acknowledge that ability is a spectrum, and all people have strengths and weaknesses (after all, 68% of Canadians wear corrective glasses - myself included). Once we accept that there is no such thing as a "disabled person", as we are all able to varying degrees in varying ways, there are only "disabilities".
Opens in a new window
Let's take this one step further - if ability is a spectrum, then the lines we draw between "able" and "disabled" are invented. They are invented not by some governing body, but by the expectations that are set by the built world. People cannot fly, and so we do not build buildings that have entrances on the fifth floor opening onto the street. People can walk up steps, and so we build entrances with stairs. Except - some people can't. And so the person who decided that a particular building should have stairs also decided that some people would be excluded from this building. Why stairs and not a ramp? A ramp would've excluded a different, and likely smaller, subset of people. It was the person who chose to build stairs who decided (probably without knowing it) where the line between "able" and "disabled" would be drawn. Disability, therefore, doesn't reside within people. Disability is located in the task and the object that sets the task.
So we can see, and this, I think, is a tremendously important idea: disability is made. If you make, then you are responsible for enabling, or disabling, people.
To make something accessible is to do your due diligence towards including everyone you reasonably can.
How do I do it?
The first step to creating an accessible product or service is to recognize how you may create a barrier for someone.
When dealing with websites (as is our focus here), it's tempting to think strictly in terms of visual impairments, since the web is primarily a visual medium. Of course, we need to also make concessions for motor impairments for user interaction. But then we need to think about cases where we serve content that isn't just visual - if we embed audio (or videos with audio content), then hearing is a concern, and if things move quickly or use visual metaphors, then we need to think about cognitive impairments and cultural context. What if we build pages that are so large that they time out on slow connections? That could create barriers for people in areas under-served by mobile carriers.
At this point, you're probably thinking, "Okay, is there, like, a list?"
The answer is 'no'. Even the government of Canada declines to give an official definition.
All of which is not to say that there aren't great places to start. The law provides us with a baseline, and there are heuristics available to us. We can also learn more about design philosophies like universal design, inclusive design, and Design for All.
The important thing is to let go of the idea of perfection. There are seven billion people and counting on the planet. There is always going to be someone that you can improve things for. Do your best, keep learning, and accept feedback.
The two approaches
We can divide accessibility strategies into two categories: open (allowing for pre-existing solutions) and proactive (creating solutions).
A strategy of openness
The first time I went to a modern 3-D movie, I was delighted to find that the 3-D glasses fit over my eyeglasses.
The theatre did not provide prescription glasses - how could they anticipate the optical needs of every potential theatre-goer? However, even the simple concession that some people wear glasses was enough to surprise me (which should tell you something about how low the bar is set for accessible design).
In a survey of nearly 1800 people, WebAIM found that 85.3% of respondents said that 'Better (more accessible) web sites' would have a larger impact on accessibility than better assistive technology. Interestingly, this number has steadily grown from 68.6% in 2009. Is the internet getting less accessible, or is assistive technology getting better? I suspect the answer is 'both'.
Assistive technology relies on open web standards - base specifications for HTML, CSS and JavaScript, plus WAI-ARIA where native semantics fall short. The purpose of a Mark-up Language is not graphic design - it is to describe content. We do this so that, while testing on assistive technology is important, what we create on the internet is meant to be consumed in ways that we do not anticipate. By building to the standards, we leave the door open for all the surprisingly competitive varieties of accessible technologies.
A pro-active strategy
Once we've done our best to not create barriers to people's individual strategies for accessing our content, we can look at what can be done on our end to reduce friction for users. Typically, web pages begin with navigation - usually the same navigation bar on every page. This is really easy for people to ignore or 'skip' visually, but for people listening to a screen reader or accessing the site using only a keyboard, this can get downright annoying. That's why a common design pattern for meeting WCAG 2.0 is a 'skip navigation' link (often visible only to screen readers or when using keyboard navigation).
Being pro-active, even when we're given WCAG guidelines, is more of a challenge for a lot of people than our 'open' strategies, for a pretty understandable reason: it requires making things usable in ways that you, personally, don't use them. It is Don't Make Me Think for people who don't think like you (at least when it comes to their default user-interface interactions). If you can, however, make these considerations a part of your process, you will become better at making things, because you will a) habitually make things that are better for more people, and b) understand that you need to question your biases with user testing.
Integrating Accessibility into Your Skill Set
At this point, you'll have started to recognize some large overlap between accessibility concerns and other design/development principles. To name a few:
- Interoperability
- Usability
- Separation of concerns
- Future-proofing
The reason that accessibility goes hand-in-hand with other best practices is because is not a distinct practice - it is, by definition, making a product or service that is robust, resilient and usable. That's why, when you make an accessible website, you also make a site with great SEO, performance and usability.
Too often, we try and advocate for accessibility as the virtuous and charitable option. I think what you'll find is that a much easier sell when you present it as 'making something well', rather than 'making something good'. When you add accessibility to your practice, it is easier to ensure a higher quality product overall.
We all have annoyances in life, and we all notice when the people who make things notice us, and give us a break. Being seen is a wonderful feeling. If you make things, take it as an opportunity to let people know that you see them.