How we build accessible products

This article was written by Lisa Hao.

At Grow, we believe affordable, high-quality mental healthcare should be accessible to all Americans. We are increasing access in a multitude of ways — working with insurance payors and companies to provide mental health benefits, partnering with the best providers to meet the needs of our diverse client population and striving to ensure that our products are navigable and usable by people of all backgrounds and abilities.

More than 1 in 4 adults in the United States live with some form of disability, and Medicaid covers 41% of non-elderly, non-institutionalized adults within this population. Serving this population has reinforced the importance of accessibility as a systematic part of how we build. Here’s how we build accessible products, and where we’re going. 

Anchoring the value in lived experiences

We talk with real clients and providers all the time to hear about their experiences and learn about opportunities to improve our product. We’ve heard from users who rely on assistive technology to run their practices or receive care. We’ve also held workshops where team members navigate our product solely with a keyboard or a screen reader to experience the accessibility of our products firsthand.

The goal is to ground the value of accessibility in real experiences so that it informs how everyone on the team builds.

Starting with the foundational layer

Since all of Grow’s products rely on a shared design system and component library, we started by making our foundational building blocks accessible. Improvements at this level scale across all products and set consistent standards. 

Alongside manual screen reader and keyboard tests, we use the axe DevTools Chrome extension to surface less obvious opportunities for improvement across visual design, navigation, and assistive technology compatibility. These insights provide us a prioritized roadmap so we could focus our efforts where they’d have the greatest impact.

Embedding accessibility into processes

Being responsive is important, but it’s even more valuable to create systems that prevent problems from appearing in the first place.

We focus on shifting from reactive fixes to prevention — embedding accessibility throughout the entire SDLC, from early planning through final QA. Concretely, that has meant:

• Creating a content design style guide with accessible language guidelines

• Adding dedicated accessibility sections to our Product Requirements Document and Tech Spec templates

• Ensuring accessible color contrast across our design system as our brand has evolved

• Introducing automated accessibility linting (eslint-plugin-jsx-a11y) in pre-commit hooks. This helped us catch issues like tab index on non-interactive elements and missing keyboard events.

These changes have reshaped how we build. We now catch many potential accessibility bugs long before they ever ship.

Consulting outside expertise

Even with stronger internal processes, there are limits to what a team can catch about its own product. Accessibility standards also evolve, and it’s important to measure against an independent benchmark. 

We maintain a partnership with Deque, a leader in digital accessibility. They help us stay up to date on best practices, starting with a month-long internal training series that covered topics from accessibility annotations and inclusive design to ARIA basics and form interactions. 

They also conduct audits of our client-facing experiences. These audits can surface additional refinement opportunities, including with font scaling behavior, heading structure, page titling, and ARIA implementation.

This combination of trainings and audits is essential, since the trainings provide the necessary context to understand and act on the audit findings. 

Giving accessibility an organizational home

Accessibility is not a one-time initiative. Without a team leading accessibility work, progress can stall; people may still care, but other priorities can make it tough to find bandwidth.

Our Frontend Foundations team drives accessibility across our platform and shared component library. While that team owns accessibility, expanding access to therapy continues to be a shared mission across the entire organization.

If you're excited about building products that are truly accessible to everyone, we'd love to hear from you. Check out our careers page for open roles.