Identifying Barriers to Accessibility

Illustration of a woman in a wheel chair watching a man pushing bricks out of the wall between them.

Several months ago, I introduced the concept of The Severity Gap which occurs when businesses make different impact and priority decisions for different segments of customers — like customers with disabilities. If not addressed, it can continue to perpetuate the inequality that exists in software development. In my last post, I started to dig into how we build our own internal prioritization frameworks and how expanding our own perspectives helps us begin to reduce the severity gap and make more inclusive decisions about how we build experiences. Expanding our perspectives starts with learning more about different segments of the population and how to recognize the barriers they face. Today, I’d like to begin to discuss disability, the unique ways that people with disabilities interact with technology, and the types of barriers that can be created for people with disabilities when we don’t consider their needs.

There are three ways of thinking about disability. The first, and least referenced today, is known as the medical model of disability. This model defines disability as “the result of a physical condition, which is intrinsic to the individual and which may reduce quality of life or cause clear disadvantages to the person.” Historically this model of defining disability focused on curing the disability in order to restore access to a “normal” life. This approach led to significant stereotypes about the capabilities (or lack thereof) of people with disabilities and a perception that their lives, independence, ability and value to society were somehow less than others.

In the early 1980s conversations began to shift away from a purely medical way of thinking. Disability advocates started to reset disability framing, moving away from the limitations of the individual and towards the idea that disability was caused by society’s failure to provide adequate support and services for people with disabilities. This gave rise to a second way of thinking about disability: the social model. The social model separates the medical condition causing the disability from the societal factors which create the barriers these individuals face. For example, the physical loss of hearing is not what creates the communication barrier faced by many people who are Deaf or hard of hearing. Rather, it is a result of society’s inability to recognize and accommodate the different way these individuals communicate.

Around 2001, the World Health Organization (WHO)reclassified the definition of disability as a combination of three factors: impairment of body functions or structures; difficulties encountered by someone in executing a task or action; and a problem experienced interacting in life situations. A third model — the “Individual-Environment Interaction” model began to emerge as it became clearer that disability was neither strictly a medical condition, nor strictly a social concept. This model, now the primary disability model used by WHO, focuses on defining disability as a “complex phenomenon resulting from the interactions between a person and their environment.” It looks at medical conditions, social and environmental factors, and how people with those medical conditions interact within those environments. If we continue our example from above, hearing loss is a medical condition. A majority of society communicates via spoken language. People who are Deaf or hard of hearing often communicate through sign language and other physical or visual methods (writing, captions, lip reading, etc.). The communication barrier between someone who is Deaf and someone who is not is created by the interaction between the two, not by the medical condition of hearing loss. This barrier can be removed if the individuals are able to find a common way of communicating (speaking the same language, using an interpreter, etc.). In terms of advocacy work and software development, the individual-environment interaction model has become the most common way of thinking about disability and the barriers people with disabilities face.

With the baseline understanding that disability is fundamentally a product of how a person with a specific set of needs interacts with their environment, let’s talk a little bit about how people with disabilities interact with technology. From my experience, we can distill this down to two categories: those who use some form of assistive technology, and those who do not.

Assistive technologies are effectively any piece of technology that is needed to help a person use any other piece of technology or interact with any environment. While certainly not an exhaustive list, assistive technologies can include things like input switches, mouth sticks, sip and puff systems, voice controls, braille displays, read aloud tools, and screen readers.

Removing barriers for people who use assistive technologies really comes down to making sure the products, services, environments and experiences you create work with these tools. It might seem like a lot of work to ensure things work with any possible number of assistive technologies. But much of the heavy lifting is done by the assistive technologies themselves. Assistive technologies interpret information provided by your application, and translate it into what’s needed by the person using it. Actions taken by the person are then translated back to your application. Barriers to use are created when the application doesn’t communicate the information needed for the assistive tech to translate effectively.

For the segment of people with disabilities who do not rely on assistive technologies there are two things to consider. First, many people with disabilities will rely on device accessibility settings (e.g. larger bolder text, high color contrast, magnification, or large UI options) to create the environment that helps them best interact with technology. Applications need to support those settings and respond appropriately. Second, people with learning or cognitive disabilities may not have obvious differences in the way they interact with technology. But, they often need to spend additional time decoding complex and text heavy environments so that they can successfully use them. And each individual may have different needs when it comes to what helps them decode information. Removing barriers for these individuals often relies on supporting a variety of customization options or alternative ways to consume content, such as read aloud experiences.

It would be impossible to articulate every possible barrier that might be created for customers with every type of disability in a single post, let alone describe how exactly to fix them all. Instead, let’s focus on a few major types of barriers with the goal of teaching you how to identify and remove them.

Functional Barriers

At a high-level, functional barriers are created when customers are unable to complete the necessary tasks or actions defined in your environment. They can include things like not being able to activate buttons or links; not being able to navigate around your application using something other than a mouse; or not being able to access, read, or interact with dynamic content in your site (like pop up messages, interactive charts and graphs, etc.). They can also be created when things simply don’t work as expected. For example, when a link takes someone to an unexpected place, when a button performs an action the user didn’t expect, or when a user’s focus ends up somewhere other than where they expected it to go.

Functional barriers are the most common types of barriers faced by people who rely on assistive technologies. They are generally caused by missing or inaccurate metadata in the application that needs to be communicated to the assistive technology. A significant number of functional barriers can be avoided by using native components and controls as much of the necessary metadata is baked into the control itself. As an over simplified example, an HTML button knows how to communicate that it’s a button. It has standard interaction patterns associated with it: you can click it with a mouse, press enter on a keyboard, activate a switch action, or touch it with your finger in order to take the action. A DIV styled with CSS to look like a button needs to have a role of ‘button’ applied to it to tell the assistive technology that it is, in fact, a button. And you need to make sure it knows how to work the way people expect a button to work.

Every control or component that you create needs to provide the right level of metadata about what it is, what it does, and how it’s intended to work to help assistive technology translate that to actions the customer can take to interact with it. Here are the core attributes that should be considered for most controls.

• Name — the visual, or non-visual label, that tells you what this thing is (e.g. “Send Email”)
• Role — the role of the control (e.g. button, link, checkbox, text entry)
• State — what the current state of the control is (e.g. active/inactive; checked/not checked)
• Value — what value has been entered into a text box or selected in a select list
• Usage Hint — added guidance about how to use the control (e.g. “double tap to active button”)

The actual implementation of these may differ across environments (HTML vs. iOS vs. Android, etc.) but, conceptually, the type of information needed is the same. If you’re building custom components, you will also need to ensure that you’ve accounted for all of the ways a control may be activated by a customer. This might include using a mouse, a keyboard, touch gestures, other forms of input devices (e.g., switches or voice access).

A lot of companies today rely on UI or component libraries to simplify their development process. Personally, I favor using standard controls wherever possible. But I also understand the efficiencies these libraries can provide — when they are built to support accessibility. The challenge is that many of them are not. So, if you are looking to use a particular component library, make sure you take a very deep look at exactly HOW it accounts for the attributes and metadata needed to effectively communicate with assistive technology. Then make sure it also enables you to extend, update, or modify those approaches to improve on accessibility support where needed.

As you start working to recognize functional barriers, ask yourself these questions:

1. Do I know what each control is and what it does? Have I clearly identified that for customers?
2. Do I know how each control is supposed to work or be activated? Have I informed developers (and testers) of expectations?
3. Are we using standard controls? If not, can we? If not, have we added all the necessary accessibility metadata so that controls will work as expected for customers using assistive technology?

Communication Barriers

Fundamentally, communication barriers exist when information a customer needs to complete an action in any environment is unavailable to them. Similar to functional barriers, communication barriers can be created when metadata (such as name, role, or state attributes) is missing or inaccurate. But they can also be created when workflows do not follow logical sequences, use simple language, or consider how visual information is being communicated.

Communication barriers are the second most common barrier facing customers who rely on assistive technology; they are the most common barrier for customers who struggle with memory, information processing, comprehension, or other cognitive disabilities (who often do not use assistive technologies).

As an example, let’s look at a multi-step purchase process. In the first step, a customer has to find an item and select it. Next they have to enter their shipping address and select shipping options. Then review or enter billing and payment information. Finally, they have to review the entire order and confirm their purchase. Most of us understand this workflow because it’s fairly common and consistently implemented today. But what if a new environment was created with a different workflow? In this new workflow, you can start searching for things right away, but you need to enter your shipping information and payment options before selecting the item to purchase. When you select items a heart turns red. When you’re ready to check out you have to click the checkmark in the “Acquisition Closeout” bar at the bottom of the screen. I suspect it would take all of us awhile to get used to or figure out this new workflow and environment, especially if there wasn’t any guidance or instructions along the way. For customers with learning and cognitive disabilities, this workflow introduces several challenges: (1) it’s different from a relatively well-known workflow; (2) the icons used don’t provide clarity — hearts mean life, or like, or love, not buy; (3) the only indication of change is color — heart turns red; (4) the words are complex — “acquisition close out” vs “checkout”. While this might seem like an extreme example, it highlights how the choices we make about words, icons, workflows, and visual information can have an outsized negative impact for some customers.

To begin recognizing communication barriers, ask yourself these questions:

1. Does this workflow follow a commonly established pattern? If not, should it? If not, are the key actions clear and follow a logical order?
2. Do the icons or images used literally represent what they mean in my environment? If not, can I change them? If not, are they common patterns? If not, can I add text to them?
3. Do the words for all buttons, controls, and instructions use the simplest language possible?
4. Am I relying only on color to convey any information to my customers?
5. Do error messages provide clear instructions for how to recover from mistakes?

Design Barriers

Designing any environment typically focuses on three areas: how the designer intends for a person to interact with the environment, what they want the environment to look like, and what information is being conveyed within the environment. As you may have guessed already, design choices can contribute to the creation (and removal) of functional and communication barriers. But I’d be remiss if I didn’t at least mention a few other design considerations we haven’t discussed yet.

Design barriers are generally the most common type of barrier faced by customers with disabilities who do not rely on assistive technologies. Thankfully many of these barriers can be avoided by making good design choices about things like text size, colors, white space, and layout. But this is also where customization options can help customers with unique needs create environments that work best for them. For customers with moderate to severe vision challenges, your goal is to make sure they can clearly see the content, or have options to make the text bigger or bolder; increase the contrast of colors; select their own colors and fonts; or magnify the entire experience. For customers with ADHD, Autism, Dyslexia, or other reading and learning disabilities, you might consider how to remove distractions like auto-playing content or increase white space to make things easier to read. For customers who rely on switch devices or other forms of input, consider how to ensure they can see where their focus point is within your environment, so they know what controls will be activated when they take action.

When looking to identify barriers in your designs, ask yourself these questions:

1. Is the text big enough? If not, can we make it bigger? If not, can the customer make it bigger?
2. Is there enough white space to make things easy to read? If not, can we add some, or allow customers to increase it?
3. Do colors have enough contrast? If not, can we change them, or allow customers to increase the contrast or change colors?
4. Are there elements on the page that are distracting? If so, can we remove them? If not, can the customer pause, change, or remove them?
5. Do I always know where I am when navigating without a mouse?

While this post does not contain an exhaustive list of the types of barriers that exist, I hope it has given you a starting point for what to look for. If a lot of this sounds like common sense, that’s because it is. Identifying and removing, or better yet, avoiding, barriers for customers with disabilities isn’t hard. It simply requires some intentional consideration of the unique ways that these individuals interact with their environment. Unfortunately, many businesses still see a focus on accessibility as an added development cost or investment that needs to be justified. So, in my next post, we’ll discuss how investment in accessibility is good for business.