Realizing Accessibility, Part 1

This article is a part of a series that will cover some practical ways for product teams, UX Teams, and stakeholders to get started with accessibility. The articles will cover topics including how to create an accessible product, resources on how to get started, how to get an accessibility budget, and UXR methods for accessibility testing.

Sophie Shrimpton
11 min readJun 28, 2021

I stood in front of the bathroom door, a crutch in each hand one day after hip surgery. I looked at the door — How the heck (I didn’t say heck.) am I supposed to use the bathroom? I can’t open the door. This is known as a temporary disability. I would heal but that didn’t help me with my most pressing problem — opening a door. Embarrassed and slightly mortified, I had to wait for someone to pass by so I could get help opening the door. This is known as exclusionary design. It is a design that does not include everyone in the experience. The non-automatic door was created as a solution for able-bodied individual, not temporary, situational, or permanent disabilities.

We come across exclusionary designs every day — low lighting restaurants where people with poor vision struggle to read the menu, buildings without ramps OR the ramp is in the back so the person on a wheelchair has to use a service entrance, and creating technological solutions that only a certain socio-economic status can afford. Oftentimes, we are unaware of these exclusionary designs because we are included in the experience. We painfully notice when we are excluded. We take for granted being included.

Why do so many people get accessibility wrong?

  1. Accessibility is commonly separated from usability. Companies believe they can use overlays or add on accessibility at the end; however, similar to how you cannot add eggs into the cake at the end, you cannot add an overlay at the end as your silver bullet to accessibility. Accessibility must be baked into your process to do it right.
  2. It’s a complex discipline to learn for developers, designers, and copyrighters. It takes a lot of time to learn how to do this correctly; without an expert on your team, it’s easily to feel overwhelmed and give up or half do it.
  3. Lastly, there’s a notion that accessible designs are less aesthetically pleasing. Therefore, some companies fall into the tap of prioritizing visuals over usability.

As Sheri Byrne-Haber notes in her Handbook Giving a Damn About Accessibility, “The reality is: your first attempt at making anything accessible will be awful; you will run into people who might make your life harder; you will learn that accessibility isn’t an add-on; and that you cannot stop at good practices, accessibility needs you to be great to provide an equal experience to your users with disabilities. Inaccessible products are broken products. The first step to fix them is to give a damn.”

Why should you care about web accessibility?

Giving a damn may look different for you or members of your company. The why may be a check the box mentality to protect the company from being sued and losing millions of dollars. For example, Nike, Netflix, and Chiptole all had lawsuits against them for failing to enable disabled consumers to experience their products in store and online. Another reason may more altruistic and related to the notion of eliminating barriers to accessing information. For example, Colorado is looking to eliminate library fines on children’s books as they’ve found these fines deter low income families from checking out books. Lastly, you/ a member of your company may have a personal connection to someone with a permanent, temporary, or situational disability. For instance, Good Grips was created to solve the need for an elderly woman with arthritis. The existing tools caused her pain and she needed a device she could hold comfortably with her arthritic hands. Good Grips solved for one person with a disability and that solution resonated with many across demographics and disabilities.

In the book Mismatch, Kat Holmes interviews John Porter who uses assistive technology to extend his own abilities. John tells about how the design of a joystick that requires two hands to play excludes him from participating. Porter notes:

“I don’t just play. I work to figure out how to play. It’s figuring out how to participate in societal moments.”

This is a great example of how products built without connecting and watching how humans with disabilities interact with the technology leads to an exclusionary design. Porter could afford assistive technology to enable him to participate. This cycle becomes more vicious when you combine design with socio-economic barriers. Not everyone can afford assistive technology and that makes solutions such as overlays even more detrimental to those who want to participate but are inhibited from doing so.

According to AbilityNet’s CEO Nigel Lewis, “The problem is that inaccessible websites and online application systems remain a big barrier for disabled people looking for a job. Over 90% of websites, for example, don’t even meet single-A compliance with the WCAG (Web Content Accessibility Guidelines) set by the World Wide Web consortium (W3C), whereas the legal minimum is AA (a higher standard than single A and lower than top compliance level AAA).”

Let’s pause to let that sink in. The way sites are being developed and designed directly impede people from getting jobs. This has to change.

How can your team get started?

The biggest challenge I faced when learning about web accessibility was where to start. WCAG guidelines were complex and seemed daunting to get right in application. I also didn’t know how to use assistive technology nor had ready access to people with impairments.

Here’s how I got started.

Start by defining accessibility with your team.

It’s imperative you find others to support the cause. I found one of the best ways to do this is by having a common vernacular. These exercises will also help your team get an accessibility budget (more on that in upcoming articles), the ability to reallocate your team’s time to accessibility, and a lot of other things. When you start by defining the problem space, you and your team have a common way to talk about it and get others passionate ignited. You’d be surprised by the passion others have for this topic too!

I define accessibility as the elimination of barriers to access. I use this when I create designs to say — Have I unintentionally interjected bias into my designs? For instance, am I choosing high contrast colors OR did I choose a color that I could see with 20/20 vision? Did I choose a typeface that can translate into other characters OR have I chosen a U.S. specific solution? Did I choose inclusive language OR did I stick to only using him or her? Have I tested my designs against WCAG guidelines OR did we test in a vacuum? (A quick side bar here — Google did the ladder method on their facial recognition ML software. The output? Because they tested this software with primarily white faces, they failed to realize their software was recognizing black people’s faces as gorillas. This is absolutely unacceptable and shows what happens when we test in a vacuum and fail to see outside ourselves.)

Be intentional with your words.

I listened to the a11y podcast on Spotify and the big idea I took away was the word disabilities is typically pretty loaded and brings forth a myriad of images, which may not include socio-economic barriers. For example, before I started deep diving, the word disability conjured up a person in a wheelchair or the far end of the disability spectrum — autism, blindness, or deaf. This narrow thinking led me to leave out those with poor vision, ADHD, homelessness, poverty, and a myriad of other barriers to access people face. Because of this experience, I use the word impairments, barriers to access, and disabilities. For me, these words are not interchangeable. I use them depending on what I want to convey.

Start by understanding the need — What do people with impairments need?

There’s no one answer. Every human is unique and every person’s experience with disabilities varies considerably based on their culture, their socio-economic status, access to education and technology, and a myriad of other nurture factors.

It is critical you engage with those who experience impairments. To do this, I strongly recommend before testing you start by Just Ask: Integrating Accessibility Throughout Design by Shawn Lawton Henry. There is a practical guide that reviews best practices for conducting these types of interviews, such as don’t pet the cute service animal.

What do I need to think about as a designer?

The answer to this question will depend on the size of your team and the level of experience your developers, copywriters, stakeholders, and product teams have with accessibility. For teams who are newer to accessibility and do not have a content team, I strongly recommend starting with an audit of your site for accessibility.

During an audit, we found that those using a screenreader were forced to read every single piece of content before moving onto the next page. (Woof.) Imagine having to read every single line in a newspaper when all you cared about was one article. That would be really frustrating.

The audit conveyed that although our team had the best intentions with accessibility, we weren’t executing on accessibility in our code, content structure or design. Our team did something magical at this point, rather than getting discouraged, our team began to gain momentum and we started to document gaps in our accessibility knowledge (cue the angels). This list enabled us to create a structure for up-skilling in accessibility.

  1. Identify: What is the team’s knowledge on accessibility? Who will lead this effort?
    I recommend starting out by understanding your and your development’s team baseline knowledge around accessibility. Your teams, including development, needs to be bought in and advocate for this effort to be successful and governed properly. If you’re starting from scratch, bring in the experts to upskill your teams. No budget for experts? Start with this basic checklist for content auditors and developers. You can also view this handoff to developers Community Figma file. There’s also a really great Udacity course that’s FREE from Google to help you and your team get started with building accessible products. Bonus: There’s a Product Manager who shows you how his screenreader works.
  2. Act on the audit.
    Our audit showed that our typeface was not scalable globally. It did not have the characters we needed to support languages, such as Chinese. Choosing a typeface correctly for accessibility and globalization is incredibly complex.
    Here are some resources and important considerations as you explore a global and accessible typeface:
    - Studies suggest that approximately 5–10% of the population has dyslexia, which is about 700 million people around the globe. This means choosing a typeface that serves this population is an important consideration. You can test your font via the pqbd test. This test will show you how easily it is for someone with dyslexia to turn letters around if the letter shapes are the exact same. There are several typefaces designed for people with dyslexia (such as Dyslexia, Open Dyslexic, Lexie Readable, Read Regular, Sylexiad, Barrington Stoke). The letters are distinct in these typefaces, making it more difficult for people with cognitive disabilities or low vision to flip or misinterpret the letter, character, or symbol. You must also think about the context in which your typeface will be used — print, digital, or both, OR global where you need to consider the versatility of characters such as Chinese or Hebrew versus one country? BBC released its new font Reith where it considered these types of challenges (cognitive disabilities, digital, print, etc.) and created a very eloquent solution.

3. Create Resources and a Training Plan for your Team.
Depending on the size of your team, you may need resources for your developers, designers, content strategists, product team, and stakeholders. Below are a few topics your team will need to consider that are just scraping the surface. I will provide at least one follow up article with additional information around this topic.

  • Alt tags — This “refers to invisible description of images which are read aloud to blind users on a screen reader. Adding ALT text allows authors to include images, but still provide the content in an alternative text based format. (Source)” Alt tags also help those with poor vision or no vision to understand the images placed on a screen.
  • Color contrast — Because disabilities and impairments are so unique, there are a variety of considerations you need to make in relation to color. Many people with low vision will increase the color contrast or invert the colors. This means that you need to design a dark mode experience and test your colors so that they meet a standard of at least 4:5.1. If you use Figma, they have several plugins you can use to check your design’s accessibility or check out this a11y tool.

4. To realize accessibility, you must integrate it from the start.
After you’ve completed your audit, your company may be tempted to eat the forbidden fruit of the accessibility overlay. These overlay tools, such as AccessiBE, promise with a few lines of integrated code, you can make your site accessible. These are bandaid solutions to open wounds and these tools can leave your business vulnerable to cyber attacks and litigation. They also don’t serve the community in the way in which they market — the AI often fails which hampers understanding and further excludes this community from participating.
If the goal is inclusion, then we must shift our thinking. We can no longer think of usability as separate from accessibility. We must do the work and engage in crucial conversations to understand people different than us. Once we do this, it becomes abundantly clear that an overlay is not a solution. You can’t add eggs to the cake at the end. You must bake it in the process.

How do I get others passionate about accessibility?

First, there’s benefit to everyone. In Just Ask: Integrating Accessibility Throughout Design, Henry notes, “Accessibility is designing products so that people with disabilities can use them. Accessibility makes user interfaces perceivable, operable, and understandable by people with a wide range of abilities, and people in a wide range of circumstances, environments, and conditions. Thus accessibility also benefits people without disabilities, and organizations that develop accessible products.”

Second, it starts with empathy. The greatest empathy I found for this audience was starting with the audit. I tried to use the site with a screen reader and instantly became incredibly frustrated. That frustration fuels drive and shared empathy. I also found watching youtube like the ones I posted in this article help garner empathy. We can connect with others when we start listening to them.

Lastly, almost every designer I have asked the question, “Why do you love design?” gives me the answer, “so that I can change people’s lives for the better.” Most of us are in this industry to make a positive impact on others. We cannot do that if we are designing for 80% of the population. If you take that approach you are failing to design for over 1.5 billion people.

Excited to know more?

A few great resources on learning and helping understand what people with impairments, disabilities, and socio-economic barriers experience regularly:


  • Kat Holmes book Mismatch
  • A Web for Everyone by Sarah Horton and Whitney Quesenbery
  • Practical Web Inclusion and Accessibility by Ashley Firth
  • Web Accessibility by Yeliz Yesilada and Simon Harper
  • Design Meets Disability by Graham Pullin



I am humbly learning this topic. If there is anything misrepresented, please let me know and I will update the article. 🙏🏻



Sophie Shrimpton

Product Designer who is passionate about eliminating barriers to access.