Or, The Why and the What of Accessibility.
I’ve written this article after a conversation about accessibility (aka a11y) with a friend who is a relatively new programmer. So that’s the general audience. You don’t need to know how to program to get the gist of this article, but at some points it might be helpful. There’s also prior art to all of this. I’m just adding a voice to my side.
As a non-disabled person, I cannot pretend to fully grapple with or understand the immensity of ableism or its myriad and complex intersections with capitalism, patriarchy, and white supremacy. I cannot solve it on my own. I build dorky little web apps. But here is what I can do: I can respect and believe the experiences of disabled people. I can build web apps that as many people as possible can use, and I can encourage my clients and peers to do the same. I can advocate for codification and stronger enforcement of accessibility standards.
Neither I, nor any other single person, nor any app, can on their or its own dismantle ableism. But I want you to take this idea for granted: If you are designing or building something and not considering how disabled people might interact with it, you are actively taking part in their oppression. Instead, I want to encourage you to question, fight, advocate, and build.
Specifically, when you build something and imagine the user, do better. Question critically, how would a blind person use this? Are the colors you’ve chosen in this graph usable by a person with colorblindness? What if someone lacks fine motor control, can they use the keyboard to navigate?
If you don’t ask and answer these questions, you are implicitly and actively, if accidentally, excluding these people. You will find, I hope, that these questions are deeply challenging and exciting and fun and rewarding; disabled people are a wildly diverse group, and the ways the interact with technology are equally diverse. Despite this, there are a few simple things you can do to dramatically widen the accessibility of your work.
It is past time to learn, but learn now. Instead of, or in addition to, thinking about how Uber for Dogs is going to improve the world, do the good work to make the world better.
Two anecdotes about resistance to accessibility in tech
If you’re already convinced on the “why”, skip ahead to the next section to read a brief primer on the “what”. Here are two personal anecdotes about the barriers to building accessible apps.
If you’re a programmer or designer, you’ve probably experienced how little time, attention, and money is given to the subject of accessibility. Business interests are orthogonal at best to the interests of humanity.
For example, at my last job, I advocated for increasing the use of Semantic HTML and ARIA Roles in a particular web app; these techniques make it easier for screenreader software to traverse the page and read it coherently. My boss told me not to spend time on it, because we had no blind users. The question of why we had no blind users didn’t occur to them. We had a greater proportion of users using an ancient version of Internet Explorer, so we spent our energy supporting them instead.
That was a story of a depressingly lazy self-fulfilling prophecy. The business thus became an anti-human cult narrowly obsessed with Internet Explorer 8. Note that I don’t think that supporting IE users is the problem here.
Here’s another story: I was working on solving a problem having to do with tab focus and browser history in React. The UI worked fine when using the mouse, but degraded severely when using keyboard navigation. My boss told me to stop working on it; not because of time constraints, but because he was concerned that I would degrade the user experience for mouse-users in my quest to make it usable for keyboard users.
That was a story of how ableism had tricked my boss into thinking that access to our work was a zero-sum game; that for one group to win, another had to lose.
What to do better
The good news is that modern browsers and operating systems are, by default, magical vortices of accessibility. They have built-in keyboard navigation, and they offer tools for zooming in, increasing contrast, and reading content out loud.
In practice, most accessibility work is simply re-enabling the built-in tools that we’ve paved over.
Here is a personal codification of the things I consider when building an app. I’m avoiding descriptions of implementation details, but if you find a glaring omission or fallacy, please let me know.
An accessible site or app
- has text which is legible, e.g. sufficiently large and high-contrast;
- does not rely solely on color to indicate important information;
- remains legible when zoomed up to 200%;
- is keyboard-navigable;
- plays nice with screenreader software like JAWS or Voiceover;
Some related ideas that are less commonly considered under umbrella of accessibility are that a site or app should:
- remain usable over a 2G or satellite connection;
- remain usable over a wide range of viewport sizes, aka responsive;
- not require the user to learn novel rules and systems;
- not subject the user to potentially triggering content without warning.
Although these last ideas aren’t related to widening access to technology to disabled people, they widen access in general. People who rely on satellite internet or 2G connections have a right to take part in technology. People whose only computer is a smartphone have a right to use our products. I would argue that there are few valid technical reasons why not.
For that last question, I am thinking specifically of interactive data visualizations, which is what I specialize in at Periscopic. These are difficult questions without obvious answers, but that’s what makes them so engaging. Let’s figure it out.