Ethical Tech

Incorporating Accessibility into Your Product


Lemon Garrett, Developer

An unfortunate reality is that accessibility is hardly taught in college CS courses. According to this study performed in 2018 by Kristen Shinohara, only 2.6% of CS faculty reported that they taught accessibility in their courses, and about 75% of the faculty responsible identified themselves as women, despite women only making up about 20% of CS professionals. Those who experience discrimination regularly tend toward educating others on how to be more inclusive—often whether or not they have the capacity or support to do so.

This shouldn’t have to be the case. Below are some of the most basic best practices to add to a checklist when incorporating accessibility into a product so that we can all be more prepared to educate and include everyone.

#1: Keyboard navigation

These are common keyboard navigation conventions: TAB key to reach individual controls, Enter and Space keys for performing an action, Arrow (←↑→↓) keys for desktop-style menus, and the ESC key for closing and/or returning to your original position. Can you navigate through the entirety of the website successfully using those conventions? Can you open and close menus, close dialogs and banners, navigate through forms, access other pages, etc? Basically, anything that you want to interact with using a mouse or touchpad, you want to be able to interact with via keyboard

#2: Screen reader compatibility

(VoiceOver for macOS and iOS, NVDA or JAWS for Windows, and TalkBack for Android.) Ask yourself: does a screen reader dictate even the most basic information you would need to be able to navigate through the site or app? When you activate your screen reader and use the site/app via keyboard/swipe gestures, does all the important information get read out? Does navigation make sense? Do forms make sense? Is your experience using a screen reader comparable to that of a sighted user’s experience?

When using VoiceOver to navigate, screen reader users often find forms riddled with alerts and unhelpful messaging (i.e. submit button is dictated as “button” rather than something helpful like “submit newsletter form”). If your website uses a form from a third party vendor, you may find that your devs lack the optionality to optimize the form’s accessibility. It is important to remember that using third-party UI tools is a risk, and they should always be audited first for their accessibility before implementation.

When a screen reader must dictate what images are, you’ll find that many images lack alt text altogether, rather than providing some useful information like, “Lemon Garrett, developer, standing at a counter”. Alt text shouldn’t be wordy or prefaced with “Image of”, the screen reader will dictate what the element’s role is—in this case, an image. There are also cases where images don’t need dictation because they don’t offer important or useful information, like an image provided solely to augment the aesthetics of a website. Simply hiding them from the screen reader’s flow with aria-hidden is a good solution.

#3: Magnification compatibility

A user should have some agency over their own devices. If they need the magnification on their devices increased overall, then your app or website should be able to accommodate that. Does the layout transform in such a way that a user with 200%+ zoom active can still have an experience comparable to that of a user using 100%? When working in React, in 2018 they updated their API to include key accessibility features.

#4: Acceptable color contrast ratio

Those with low vision or color blindness have trouble with color pairings that don’t meet WCAG standards. Try using WebAIM contrast checker to learn more about acceptable ratios and see if your site’s colors pass.

#5: No rapid or flashing animations

Make sure the website doesn’t have any content that flashes more than three times within a second, and that any constantly moving content is able to be stopped by the user.

#6: Ensure options

Is there more than one way to accomplish a task? For example, closing a menu by clicking an interactable UI element, like a button, or pressing ESC; zooming in on a map by either using the mouse wheel or a “zoom” gesture on a phone, or using +/- buttons.

You can use Lighthouse to run a surface level analysis of your website’s accessibility and performance levels. The caveat with relying on Lighthouse to determine your site’s accessibility is that, as their audit report states, “Only a subset of accessibility issues can be automatically detected so manual testing is also encouraged.”


Repeatedly asserting that integrating good accessibility practices into your own or your company’s workflows by stating, “It’s the right thing to do!” won’t always win leadership or your clients over. From the perspective of an executive, some points that could make a case for giving your cross-functional teams the time and support to learn about accessibility and how to efficiently use assistive technology so that they can effectively and iteratively test their work might be the following:

  • Your products will be universally accessible with an increased ease of use and better SEO, therefore encouraging more users to enjoy (and pay for) your products.

  • Somewhat tragically, accessibility is so often deprioritized in tech that integrating it into your product will create a competitive edge regarding both user engagement and employee recruitment/retention.

  • Furthermore, your company will be safe from WCAG-related lawsuits. (Just this once, don’t be like Beyoncé.)

Oftentimes we find that when we design for all, we actually surface solutions that are ultimately better for everyone—leading to stable user experience and engagement. The bottom line is: accessibility knowledge is something one generally must seek out on one’s own initiative. Disability is not something anyone should have to overcome - it is something we as product designers, developers and so on should learn how to effectively include to provide the most basic minimally viable experience for all users.


  1. Marcy Sutton’s Website

  2. “Accessibility For Everyone” by Laura Kalbag

  3. Lighthouse

  4. What is assistive technology?

  5. Accessibility Checklist

  6. Developing an Accessibility Statement

  7. Cypress

Lemon Garrett (they/them/she/her)

Developer, Substantial

A bit of a renaissance person, Lemon spent eight years as a traditional artist before eventually transitioning into a career as a software engineer, and found their way to Substantial in October 2019. As a full-stack developer, Lemon is a steadfast accessibility advocate and a zealous promoter of diversifying the tech industry in pursuit of creating and maintaining a more inclusive, supportive environment. Passionate about leveraging their knowledge in order to help make web and mobile apps universally accessible, Lemon is constantly seeking new, straightforward ways to integrate accessibility best practices into their teams’ workflows and approach to development.

Let’s build a better future, together.