Confronting ableism to build a more inclusive web

Web software, like all technology, amplifies the priorities of the people who build it. What does that say about our commitment to web accessibility?

It’s been more than 30 years since the passage of the landmark Americans with Disabilities Act, and more than 15 years since the release of Web Content Accessibility Guidelines 2.0. Tools and instructions for building a more accessible web are plentiful, and yet today’s web practitioners still struggle to build an accessible, inclusive web.

If web practitioners want to make the web a better place, we must confront our priorities. We must talk about ableism.

Notes on language

As we enter this discussion, it’s important that we work from a shared understanding of some key terms.

Ableism

“A system of assigning value to people's bodies and minds based on societally constructed ideas of normalcy, productivity, desirability, intelligence, excellence, and fitness. These constructed ideas are deeply rooted in eugenics, anti-Blackness, misogyny, colonialism, imperialism, and capitalism. This systemic oppression leads to people and society determining people's value based on their culture, age, language, appearance, religion, birth or living place, [‘health’ or ‘wellness’], and/or their ability to satisfactorily (re)produce, ‘excel’ and ‘behave’. You do not have to be disabled to experience ableism.” (Lewis, 2022)

Anti-ableism

The practice of opposing ableism and promoting liberation for Disabled people.

Assistive technology (AT)

“[A]ny item, piece of equipment, or product system, whether acquired commercially off the shelf, modified, or customized, that is used to increase, maintain, or improve functional capabilities of individuals with disabilities.” (U.S. Tech Act of 1988)

Disabled

According to the Americans with Disabilities Act, a person is Disabled if they have “a physical or mental impairment that substantially limits one or more major life activities, [a] history or record of such an impairment, or [are] perceived by others as having such an impairment."

While this definition is a useful starting point, it’s important to remember that disability is complex and nuanced. Disabled people do not always fit neatly into legal or medical models of disability. If someone says they are Disabled or that they need an accommodation to succeed, we should take them at their word.

“Disabled person” or “person with a disability”?

There are two common ways to refer to disabled individuals: identity-first language (“disabled person”) and person-first language (“person with a disability”). Both of these forms of language are fine to use, but this article will use identity-first language. Identity-first language is a growing preference among Disabled people, especially people who engage in anti-ableist and disability justice work.

Disabled people are not a monolith. If you’re unsure of how to refer to someone, ask them. As you interact with Disabled people, remember: “Disabled” is not a dirty word.

Ableism by default

Whether made by a team of professionals planning, delegating, and executing their roadmap, or by a solo developer tinkering away in their spare time, all software is a product of human labor. While no two teams and no two web practitioners are alike, there are trends across the industry that reveal the priorities we carry into our work.

The accessibility (or lack thereof) of web software starts with the assumptions made in the research process. Many web practitioners work on high-powered computing devices, with high-resolution desktop displays, high-precision pointer devices (mouses), and high-speed bandwidth connections. Because we spend much of our professional time in these environments, we often assume that our users are in similar environments. Moreover, we assume that our users interact with their hardware the way that we do; we assume that users experience the world in the way that we do. Though nearly 60% of global web traffic comes from mobile devices, we assume our way into a web where everyone is sat at a desktop with a high-speed broadband connection, using full color vision to precision-click the interfaces in front of them.

Design is the first point at which our inaccessible research assumptions metastasize into accessibility barriers. Motivated by sighted-user-oriented user research, designers are often concerned with how things look instead of what they are. Large text is just large text, with no consideration for heading semantics; every interactive element is a button, even when it should be a link; and large, complex components are treated like buttons when they should be broken out into multiple discrete interactive elements. A designer can spend hours thinking about visual component variants, layout, and font-sizes across multiple screens without ever considering the keyboard experience. Some popular design tools such as Figma allow for the creation of “interactive” prototypes, but these prototypes can only be configured with touch targets and do not support any kind of keyboard input by default. Even with their focus on visual design, design tools often don’t have first-party color contrast checkers. Finalized designs do little to challenge our initial assumptions: everyone is a high-speed-connected, high-resolution-screen-viewing, fine-precision pointer user who has never heard of a keyboard.

Developers carry a design’s assumptions forward into their HTML, CSS, and JavaScript. Large text elements become <p> tags (or worse, <div> tags!) that do not bring any structure to the page; interactive elements respond to pointer input, but may or may not respond to the keyboard at all. Even when something supports keyboard input, it may not have a visible keyboard focus indicator. Developers do not know which ARIA attributes to add to their components (if any are necessary), and they don’t programmatically manage keyboard focus to help keyboard users navigate the page as it changes.

Once developed, new features undergo manual QA testing, where someone—sometimes a dedicated QA tester and sometimes the developer who built the feature—will verify that the feature behaves as expected. The tester clicks through each stage of the feature, but they rarely (if ever) verify that all of their user interactions work with the keyboard. These testers are even less likely to test with a screen reader or any other assistive technology; they may not even know how to use any assistive technology at all. When our feature leaves QA, it will have further cemented our product’s focus on sighted pointer users, leaving behind users who rely on any other devices.

Automated testing can help developers safeguard the stability and functionality of their software, but most testing tools, too, adopt the interaction model of a pointer user. Depending on the library and environment, keyboard interactions can be difficult to simulate in a way that mimics real user interactions, to say nothing of any assistive technologies. Even when developers want to build more inclusive test coverage, these tools make it difficult or impossible to do that well.

At the end of this cycle, a product goes out into the world. It’s a technical artifact, but it’s infused with our human, social mores. Inaccessible software is not the problem; it’s the symptom. The purpose of a system is what it does, and what this system does is reinforce ableism. When our product undergoes further development cycles, the system will propagate more ableism.

To change our outcomes, we have to change the system.

Challenging the default

Faced with the task of changing a system, it’s easy to feel despair; to think that the problems are too big, that our processes are too enshrined to really change. The truth is, if a system can be made, it can also be changed. With strategy, care, and commitment, we can build cultures that resist ableism, produce accessible software, and tear down more barriers than we create.

Language is the first vector of change within social systems. To challenge ableism, we must first get comfortable talking about disability. Avoid euphemisms like “differently abled”, “special needs”, or “user with accessibility needs.” Refer to your Disabled users, friends, and colleagues simply as “Disabled people” or “people with disabilities,” as mentioned earlier. While discussing the ways in which someone interacts with their computing devices, refer to them as a “screen reader user” or an “AT user”, just as you might call someone a “mouse user” or “keyboard user.”

A commitment to web accessibility is hollow if we don’t empower our teammates to succeed. It’s important to conduct accessibility audits of our software properties, and to hire practitioners who understand accessibility, but accessibility initiatives can’t thrive unless people at all levels of an organization, across all product disciplines, are empowered to understand and remediate accessibility issues.

Devon Persing describes the concept of accessibility literacy as the ability to recognize a need for new information, find that information, assess its accuracy, and share it with others. As accessibility literacy develops, organizations should set measurable, concrete, and actionable accessibility goals so that everyone understands the current state of the accessibility commitment, how their work supports that commitment, and what they must do to succeed.

Kate Kalcevich from Fable Tech Labs published an article about accessibility key performance indicators (KPIs). Accessibility KPIs can help teams streamline vast, seemingly shapeless accessibility requirements around specific questions that can then be used to shape specific goals. For example, the question “Do teams have the necessary skills to address accessibility issues?” can be mapped to a goal for 60% of team members to complete accessibility training before the end of the year. That goal, in turn, can be the impetus to deploy accessibility training materials to our team, which will pay dividends to the health of our organization and its software.

Dr. Michele Williams discusses strategies for including Disabled users in otherwise inaccessible ecosystems, an important step as we move toward more accessible defaults.

The right tools can help us to better focus our work as we improve our accessibility posture, as well. For example, popular design tools have plugins that help designers ensure the accessibility of their work. Developers can add linters to catch some accessibility issues early on while tools like Deque’s axe DevTools can help identify a subset of accessibility issues that may appear in production.

Where possible, it’s important to pick tools that put accessibility first, or that otherwise make accessibility easier on the people responsible for building our software. Cypress, a popular end-to-end-testing library, espouses a user-focused testing approach that can help teams ensure some aspects of their products’ web accessibility and Assistiv Labs offers an end-to-end accessibility testing service that takes an accessibility-first approach by driving actual screen readers to ensure user flows are able to be completed by users of assistive technologies

Committing to the work

It feels good to hit our accessibility goals—adopt new processes, train our teammates, remediate critical issues—but we must remember that accessibility is a continuous process, not a destination. As long as software development happens in the context of an ableist workplace, it will risk excluding Disabled people; as long as a software product is in active development, it will have accessibility defects.

A pessimist could see us web practitioners as Sisyphus pushing an accessibility boulder uphill for all eternity. I prefer a different view: this work is an opportunity to serve Disabled people, to build better, stronger communities, and to make the web better for everyone.