Why Software Accessibility Matters
I’m a designer with Color Vision Deficiency (CVD). A lot of people, myself included, refer to CVD as “color blindness.” The term “color blind” can be a bit misleading and gives rise to all kinds of funny questions like, “What color is my shirt?” or, “How do you dress yourself?” The reality is, I do see colors. But have a hard time distinguishing some colors (green and orange, for example). CVD is surprisingly common, affecting roughly 1 out of 20 people.
Occasionally, someone might ask, “How do you do your job?” I don’t mind this question, because it creates an opportunity for discussion and learning. CVD does make my job as a designer slightly harder, but it’s not difficult to overcome. Besides, I reason that if I can’t distinguish two colors in a user interface, other people might have a hard time too.
Unfortunately, I have had experiences with past employers telling me I could not take on certain design tasks because of my impairment. I accepted this because I had internalized the idea that my impairment made me unfit for the job. It took time for me to recognize this for what it was – discrimination.
Despite having some first-hand experience with these issues, I have discovered that I still have so much to learn about accessibility and disability. Recent discussions within my teams have revealed that I’m not alone. The truth is, we just haven’t had many conversations about accessibility.
Maybe it’s time to have that conversation.
What is Accessibility?
The word accessibility might call to mind things like wheelchair ramps, signs with braille, or closed-captioning on videos. More broadly, when we talk about accessibility, we’re usually describing added features that accommodate people with disabilities. We added ramps to buildings after we realized that the stairs, which work fine for most people, were an obstacle for others.
Unfortunately, if we frame accessibility as an “add-on”, it can lead us to view these features as secondary to the “main” user experience of our products. As a result, accessibility becomes an afterthought, is given a lower priority in our product design and development process, and in the worst of cases, is treated as optional or “nice to have.”
Maybe you’ve heard things like this in your discussions about software accessibility:
- “Accessibility isn’t in our budget.”
- “We don’t currently have any disabled users.”
- “We hope to address accessibility in a future release.”
- “We don’t know how to make our product accessible.” (at least this one is honest)
More likely, discussions about accessibility just aren’t happening at all. A recent audit of 1 million websites found that upwards of 98% of websites had one or more significant accessibility issues.
Suppose we start to include people with disabilities in our design discussions, and we train ourselves on the tools for developing accessible software. We will still face questions like, “Do we have time for this? Is it in our budget? What’s the return on investment?”
To answer these questions, we have to step back and look at accessibility from a different perspective. There are benefits to creating accessible products, including better overall usability and a wider market of users. There are also risks in deprioritizing accessibility, including exposure to lawsuits (a topic I’ll be exploring in a future article). But I think there’s a more compelling reason why we should make accessibility a priority.
Inaccessible products create disability.
To understand this further, we have to dispel some myths about the nature of disability.
The Social Model of Disability
The prevailing view of disability before the 1960s was the medical model of disability. Under this model, disability is viewed as an individual attribute and the solution is to fix people’s bodies. Adherence to this model of disability has resulted in disproportionate resources being directed towards individualized solutions, segregation of disabled people from the larger community, and a failure to address systemic causes of disability.
Over the past few decades, the discourse on disability has shifted toward a social model of disability. Under the social model, disability is not treated as the inadequacy of human bodies to meet challenges in their environment, but rather, as the inadequacy of societies and environments to address the needs of people with different abilities.
This idea shouldn’t be unfamiliar to those of us in the world of software development – it’s just human-centered design! When there are breakdowns in our interactions with software, we understand that the software is almost always to blame, not the user. Accessibility is no different. Rather than seeing some users as unfit for our products, we can instead see inaccessible products as unfit for use.
Disability in Context
According to the World Health Organization, 15% of the world’s population, around 1 billion people, experience some form of disability today. This includes those with a range of visual, auditory, motor, cognitive, communication impairments. Understanding disability as a relationship between people and their environments allows us to see it as dynamic, temporal, and context-specific.
An impairment can be permanent, such as a loss of limb or congenital blindness, or temporary, such as with someone who is recovering from an injury or recent surgery. A person may experience situational impairment, such as difficulty hearing a conversation in a crowded bar or difficulty focusing on a task in the presence of distractions. As we age, we naturally tend to experience declining vision, hearing, mobility, and cognition. As a result, most people will experience disability at some point in their life.
Cultivating a Mindset of Inclusion
There is no such thing as a perfect or “normal” human being. Impairment is a fact of life and a part of the diversity of the human experience. So when we assume that our users’ bodies, senses, and cognitive faculties are always fully enabled, we are more likely to create moments of disability in our products. To overcome this, we have to start seeing all of the diverse ways in which people experience and navigate the world as equally valid.
For example, suppose you are curating content for a website. A user with impaired vision may not be able to see your content, but they can hear it via a screen-reader – an assistive technology that reads web content aloud – if the site is built to support this. What’s important is that they can perceive and interact with the content in a way that meets their needs and suits their abilities. Semantic HTML elements and ARIA attributes (topics I’ll be exploring in future articles) are just as critical for your vision-impaired users as CSS is for sighted users.
Unfortunately, many of the things we interact with every day – doors, crosswalks, public restrooms, etc. – were built without consideration for or input from people with diverse needs and abilities. It has taken decades of activism, policy change, and a lot of hard work to make these physical environments usable for people with disabilities. We’ve still got a long way to go towards true equality. I wonder how things might be different if accessibility had been a goal from the start.
As makers of software, we are the architects of the digital world. The products we create are increasingly becoming the primary way for people to enjoy their fundamental human rights: education, employment, housing, health care, finance, arts, culture, information, and entertainment. That means we have a great responsibility and an incredible opportunity. We are uniquely positioned to build this world in a way that honors diversity and affirms the right of everyone to participate fully and equally.
More To Come
I hope this article gets people thinking, starts some conversations, and brings more awareness about why accessibility matters, as well as the role we play in creating an accessible and inclusive world.
Be on the lookout for more posts where I plan to explore topics like:
- The legal landscape of digital accessibility
- Web Content Accessibility Guidelines (WCAG 2.1)
- Overview of Assistive Technologies
- Accessible design and development techniques
- Accessibility testing
World Health Organization – World Report on Disability
Microsoft’s Inclusive Design Toolkit
The WebAIM Million – An annual accessibility analysis of the top 1,000,000 home pages
24 Accessibility – How Ableism Leads to Inaccessibility
Oliver, Michael, 1945-2019. (2012). The new politics of disablement. Barnes, Colin, 1946-, Oliver, Michael, 1945-2019. Houndmills, Basingstoke: Palgrave Macmillan.