Questions about accessibility with Match? Reach out to the Slack channel #help-match-dsys.


How we build inclusive experiences at Twilio

Building an accessible, inclusive web experience means considering users with disabilities that span across auditory, cognitive, neurological, physical, speech, and visual impairments.

According to UsableNet, the latest web accessibility statistics as of 2020 are:

  • Over 1B people, or approximately 15% of the world's population, are estimated to live with some form of disability
  • About 217M people have moderate to severe vision impairment, which is expected to triple by 2050.
  • The average person with a disability can expect to spend 8 years, or 11.5% of their life, actively managing their disability.

The Match team is working to design and build a design system that achieves 100% WCAG (Web Content Accessibility Guidelines) AA accessibility compliance so we can provide a better web experience for all users, such as those who use assistive technologies and/or have visual impairments. There are three levels of WCAG compliance:

  • A - minimum level: the Web page satisfies all the Level A Success Criteria, or a conforming alternate version is provided
  • AA - more accessible: the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided
  • AAA - even more accessible: the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided

To review criteria, please review the WCAG guidelines here. However, in this document we will be showcasing the top ways you can ensure the design and development of your product meets AA compliance.

Most companies and products aim to achieve AA compliance because while AAA is awesome, it is difficult to meet while balancing visual and UI design and brand identity. Additionally, meeting AA compliance puts companies at less risk of facing legal action for inaccessible business web platforms.

The Match team builds with accessibility in mind to represent the Twilio Magic particularly “Wear the customer’s shoes” and “Be Inclusive”. We design for the needs of every user by paying attention to color, typography, and coding standards.


Best practices to using color with accessibility in mind

The use of color is a key element in a design system. It can invoke emotion, personality, and represent the identity of a brand.

Twilio’s brand palette has an extensive number of colors and the Match team has identified how colors should be used, such as for text and background colors.

Some colors are better suited for action items such as buttons and anchors, whereas many colors belong to the extended palette, where they are better suited for illustrations and supporting UI graphics. Please refer to our design tokens page to see how colors are used for Twilio and Sendgrid.

The way the Match team has made decisions on how colors are used is to follow WCAG’s guidelines around color contrast, which mention that all “text and interactive elements should have a color contrast ratio of at least 4.5:1.”

Luckily, there are many tools where you can easily plug in the text and background color values to find out if your colors meet that contrast ratio.

Here are some of our favorite resources:



Figma Plugins:

A11y - Color Contrast Checker

Able – Friction free accessibility


Best Practices: The Dos and Don’ts of Color

  • Use text and background colors that have a color contrast ratio of 4.5:1
  • Include a visible focus state on interactive elements so users who navigate with a keyboard can easily distinguish where they are on a page
  • Red and green colorblindness is one of the most common in users with visual impairments - avoid using these colors, or do not depend on color alone to convey a message.
    • For example, red is often used as an error state. Use other indicators such as icons or helper text to convey an error message.
  • Be consistent with colors! Use the same colors to mean the same thing across your product

Use Case: Buttons on

The following is a specific case study of how we improved a component that was failing the color contrast ratio under WCAG guidelines.

Prior to the button redesign,’s button background color was Twilio’s primary brand color (#F22F46). It was paired up with white text and we found that the color contrast ratio was 3.98 and failing AA compliance. Additionally, in a benchmark study conducted to understand users' thoughts on the look and feel of, multiple people mentioned the red made it seem like they were in a continuous state of error. We knew that we had to carefully use our primary brand color in more subtle ways and in components that are not actionable.

Buttons on are now blue and meet WCAG compliance. We found that the blue palette allowed us to have accessible default buttons and meet a minimum of AA compliance for active and focus states. We were also able to create matching secondary and tertiary button sets for CTAs of lower importance. Even though red is our primary brand color, it was important to consider our users first and use it sparingly as a color used mainly for non-interactive elements such as illustrations.

Interested in learning more? Check out our button component article!


Best practices to using typography for accessibility

Typography is incredibly important because it enables users to engage with complex and valuable information. With such an abundance of content on, it is incredibly important for our typography choices to follow best practices around accessibility. Here are some of the guidelines that the Match team follows around typography:

  • Use text colors with enough color contrast against the background color.
  • Avoid using all caps, especially at smaller font sizes. Screen readers read capitalized text letter-by-letter, rather than by each word. It is also harder to read text that uses all-caps, especially for users with autism and dyslexia.
  • According to WCAG, “a readable line length is between 50 and 75 characters per line, with 66 characters considered the ideal. Text with more space between lines can have somewhat longer length.” Our paragraph styles have a larger line height than our header text styles because body copy tends to be longer in length and content.
  • Text should be scalable without loss of content, clarity, or functionality—even when assistive technologies are not being used. WCAG recommends that text is scalable up to 200% of the original font size.
  • Avoid using description text in images because screen readers will not be able to pull that content.
  • We recommend using alt text for every image so users with assistive technology can understand an image too. Alt text is also useful for users with slower internet speeds - it will display when an image is unable to load.
  • Don’t skip headline hierarchy! This is important for our users using screen readers to understand what headings have a bigger importance or chronological value in a page.

The Invisible A11y

Less obvious, but equally important elements to make your product accessible

“A11y” is a common abbreviation for web accessibility. Making our products accessible isn’t always as visible as checking the colors and typography we use. It’s equally important when building web pages to make sure it's usable and has an equally engaging experience for all of our users. Here are some ways the Match team builds out accessible components and patterns:

  • Use alt text for images, components, icons, and logos
  • Build in keyboard accessibility to allow users to navigate through every functionality and interaction on the website. The navigation is key to helping our users find the information or resources they need. Add a “Skip to Navigation” link that is only visible to keyboard focus users to help them navigate through the information architecture without a mouse or trackpad.
  • Make use of ARIA (Accessible Rich Internet Applications) attributes so that interactions and functions on a website can be passed to users using screen readers or other assistive technologies.
  • Use Match’s Visually Hidden component to provide assistive technology users with additional or contextual information, which may be inferred by sighted users and which you cannot provide with semantic HTML.

To Conclude

Check the boxes described in this article, and you will be on your way to creating lovable experiences for every user. Every component and pattern is designed and built with the user in mind.

The Match team is committed to putting accessibility first, while conducting user research to provide a great experience, and balancing Twilio’s brand identity. With every component we build, we include accessibility guidelines to provide direction on how to build responsibly. As we continue to grow Match, Twilio’s brand marketing design system, we will continue to be an advocate for accessibility and “wear the customer’s shoes” every step of the way.

Other great resources to check out:

A11y Project

A11y Style Guide

Apple Developer


Mozilla Developer