Skip to Content

Accessibility Thinking

An inclusion-centric design approach to creating digital products for all users.

Start with your users

When designing a product or service, start with your users. Your first challenge is to try to understand them as people.

This way of thinking is captured in the idea of inclusive design; it asks designers to empathize with the user, understand their needs, and create intuitive and usable solutions based on that understanding. But what if those users experience a wide range of disabilities, as an estimated 16% (1.3 billion) of people in the world do? What if they can’t see your well-designed screen or hear your well-designed audio? Or if they have limited dexterity and don’t use a mouse or don’t use a keyboard? Or if they use a colored filter and a screen magnifier to make content on the screen monochrome and zoom into only a portion?

“67% of accessibility issues originate in design.”

—Sujasree Kurapati

Taking responsibility

We always start from the bedrock understanding that we who design and build the interface are the ones responsible for the success of the user experience. That might seem obvious (after all, who else could be responsible?). Still, it is easy to find accessibility advice that starts by focusing entirely on user deficits: cataloging the range of medical conditions and limitations users can have. While this is obviously relevant, consider how much less disabling those conditions and limitations would be if we removed any barriers users face in our websites by addressing each need in our design.

The needs-centered perspective assumes that disabled users are simply users and that it is on us to design and deliver an interface that meets their needs. By contrast, the disability-centered perspective focuses on the reasons that limit users who try to use our interface, implying the design of the interface is a given and it is a user’s condition that prevents them from using it as we intend. It’s a subtle but critical shift in responsibility from the user and onto the people who are most able to fix the mismatch: us.

When resources are limited and deliverables have to be prioritized, it can be easy to start talking about those users, who cannot use our interface. Continually refocus the conversation back to us, the people who have not provided the most suitable interface for all users.

Here are some essential questions you can ask to get back on track:

All users

It’s important to define what we mean when we talk about “all users.” This short phrase includes a hugely diverse range of human beings: many with disabilities, some who have trouble seeing or hearing, folks who may not be comfortable using computers or who aren’t familiar with the website’s interface, people who may be distracted, or rushed, those who have low or no reading skills, those who aren’t native speakers of the language of the website content, and more.

In addition, when accessing the web, every user’s experience will be filtered through the lens of whatever technology they use. For those with disabilities, assistive software and devices will dramatically alter how they perceive and interact with your interface. Part of the positive challenge of Accessibility Thinking is to empathize with such a diverse range of users, abilities, and technologies that make up our audience.

Know your user

Conduct user research. Talk with disabled users; invite and listen to their input and feedback to see what works for them and what you can improve to lower any barriers that may have made their way into your interface. Users who are most likely to experience barriers are the most valuable for you to learn from since they will be the first to identify otherwise subtle problems that ultimately affect every user.

It’s not the user’s fault your interface failed

The social model of disability, which we advocate, asserts that disabilities are only limiting in the context of the barriers that prevent people from fully participating in society. These barriers can take many forms, such as physical, attitudinal, and systemic. In this model, the concept of “disabled” is a socially constructed condition rather than an intrinsic trait.

The implication of this change in perspective is profound: if we deliver inclusive user interfaces, we remove the disability people could experience when accessing our content.

“I don’t consider myself ‘disabled.’ I’m lucky enough to have technology that allows me to access everything I need.”

—Technology and Me by Molly Watt

Accessibility and users’ needs

Since our day-to-day work is focused on understanding and meeting users’ needs, it makes sense to think about the types of needs disabled users may experience.

Needs text

Users who access the web using assistive technologies such as screen readers or Braille displays rely on text content. Providing alternative text for images, graphics, and other visual elements on a web page helps to remove barriers for these users.

In addition to assistive technologies, alternative text is also helpful for users with limited connectivity. In those cases, images or other visual elements may not load properly, and alternative text can help these users understand what content is missing.

Needs flexibility

Assume and embrace the idea that users may override your interface to suit their needs as they access the content. Providing a robust and flexible interface means it can be accessed by more users. If the content is designed to be viewed or listened to, ensure that it can also be read. If an interaction is designed to time out in 4 seconds, ensure there is a way that a user can take longer if they need to. If the navigation uses mouse events and hover-based animations, ensure that users can still use it without a mouse.

As another example, consider using color to communicate information and ask how this meaning could be accessed without color. This thinking will benefit a wide range of users:

  1. Users who need to distinguish content without being able to perceive a full spectrum of color. Web content that relies only on color to convey information may be inaccessible to these users.
  2. Users who need or prefer a forced high-contrast color mode to read and navigate web content. Web content that has a fixed, low contrast value may be inaccessible to these users.
  3. Users who need culturally-independent symbolism to understand meaning. Web content that assumes a universally-shared meaning to certain colors (yet green can mean “go,” “jealousy,” or “illness”; red can mean “stop,” “love,” or “good fortune”) may be confusing to these users.

Having multiple ways that different users can derive the intended meaning from content, beyond only color for example, means more people are better served by our design.

Needs it to work with assistive technology

Disabled users are more likely to employ a wide range of assistive devices and software to access the web. Ensuring that web pages do not exclude those users is crucial. Consider, for example, the following list of common assistive technologies:

  1. Screen readers with text-to-speech modules will read the text on a web page aloud, allowing users who cannot see or who benefit from hearing text as they read it, to understand content.
  2. Braille displays use raised pins to display text in Braille, allowing users who primarily consume written information as Braille to read web content.
  3. Speech recognition software allows users with difficulty typing or using a mouse to navigate the web using voice commands.
  4. Magnification software enlarges the text and images on a web page, making it easier for low-vision users to read and interact with the content.
  5. Alternative input devices, such as switches, joysticks, and touch screens, can be used by users with physical disabilities to more easily navigate and interact with web content.

Needs clarity

While all users benefit from clear, easy-to-understand content, some groups are more likely to experience barriers related to lack of clarity. Individuals with reading-related, neuro-cognitive difficulties, or non-native language speakers may find complex text, lengthy passages, or overly abstract concepts tricky to follow. Simple, concise, and straightforward language can help these users access the meaning of content on a web page.

Using plain language, avoiding idioms, jargon, or slang, and providing definitions for technical terms can help make content more accessible to these users. Consider, for example, an error message that could be worded, “Invalid user input string,” versus “Check the email address you gave us, it looks like you may have mistyped it.”

When designing patterns and interactions, follow user expectations, or as the author Steve Krug puts it, “Don’t make me think.” Innovation and novelty have their place in good design, but some cognitive and neurodivergent conditions mean those users will experience barriers from novel or unexpected interfaces.

“People don’t want interfaces to surprise them; they want things to be intuitive and behave as expected.”

—Predictable: Make Web pages appear and operate in predictable ways

The problem with pigeonholes

We organize our work using categories, but people are not categories. Asking whether an interface is suitable for a blind user or a deaf user, for example, ignores the existence of the up to 2% of people globally who are deafblind, having both a hearing and a sight impairment.

Social, cultural, and economic conditions are also influenced by and contribute to users’ experience of disability. For example, in the UK, government statistics show that 27% of people with disabilities live in poverty, while only 21% of people without disabilities do. A lack of access to resources may primarily limit a person with disabilities who is also experiencing poverty: their financial status can make it impossible to get a formal diagnosis which may require them to find, organize, travel to, and pay for medical testing. In turn, without a formal diagnosis, they may be unable to access benefits and services that enable them to work.

Experiencing poverty also compounds barriers to digital access. Online resources designed for the latest software, operating systems, and devices systemically exclude those unable to afford to regularly upgrade.

Notice Needs are not pillars; they combine, contribute, exacerbate, and overlap with one another. This intersectionality of conditions can mean we should consider combinations of needs as a regular matter of practice. Users who need text alternatives may be more likely to need plain language, for example.

Perfect accessibility and other illusions

Ideally, we would aim to deliver software that does not exclude anyone; unfortunately, the practical reality is that this isn’t always realistic. Even with infinite time, knowledge, and resources, different needs will require different approaches, and what works well for one group of users may not work for another.

Artfully balancing conflicting needs is a well-understood goal in the design field, and it is no different when designing for the needs of disabled users. Consider the possible conflicts we may have to contend with:

When facing conflicting needs, it is important to take a considered, holistic, and practical approach to accessibility. This will involve a frank assessment of what is possible, prioritizing needs over preferences, offering users options where possible, and taking an ongoing testing and refinement approach to incrementally improve accessibility.

Considered exclusion

If we accept that perfection is an unreasonable standard, then we must expect that at least some users may experience some amount of exclusion some of the time. In that case, the red line for us then becomes the decision that this exclusion will be delivered through a process that is honest, considered, and deliberate rather than the result of whatever haphazard shortcuts happened to be picked when delivery deadlines started to loom.

Agree on a plan for rolling out accessibility in a realistic way. This should include stakeholders representing business, design, development, and testing. Ideally, at least one of the decision makers will be asked to serve as an “accessibility advocate,” having additional training and responsibility to constantly ask, “How will this affect our mission to deliver effective accessibility?”

  1. Identify the most critical accessibility issues: It’s vital to understand and acknowledge the most common and essential accessibility issues that affect the website’s disabled user base. For example, keyboard navigation, screen reader compatibility, and color contrast at a minimum. Meeting this needs baseline will mean it is much easier to address more complex needs later on.
  2. Prioritize accessibility issues: Once the most critical accessibility issues have been identified, prioritize their delivery based on their severity and impact on the user experience. This will help you focus on the most pressing problems first and allocate limited resources most effectively.
  3. Refer to accessibility guidelines and standards: Established accessibility guidelines and standards, such as the Web Content Accessibility Guidelines (WCAG), are a good way to establish a baseline and a starting point.
  4. Make good use of automated accessibility testing tools: Automated accessibility testing tools can never address all (or even most) accessibility testing needs. However, they can help identify many common accessibility issues quickly and efficiently (the lowest-hanging fruit). These tools can help you prioritize and address the most critical issues first.
  5. Seek out feedback from disabled users: Soliciting feedback from users with disabilities can provide valuable insights into the most critical accessibility issues and help ensure that the website is accessible to the broadest possible audience. Be careful, however, to avoid drawing general conclusions from small datasets. Statistically speaking, feedback from a handful of users can only prove what that handful of users thinks. Understand the different uses of qualitative and quantitative data.
  6. Document your efforts: Keep a record of your accessibility goals, decisions, actions, and any resulting progress. This documentation can be used to demonstrate your commitment to accessibility and to identify areas where further improvements may be needed in the future.