By Josh Saint Jacque and Michelle Matthews
Today is Global Accessibility Awareness Day. At Brightline, our mission is to deliver quality virtual behavioral health care to all kids, teens, and families who need our services. In order to deliver on that mission, accessibility is non-negotiable and has been centered in our product development process. Every team member across the product and engineering teams has been required to make a meaningful investment of time and learning. And it’s worth every second.
We’ve spent the last several months auditing and improving our product to ensure Web Content Accessibility Guidelines (WCAG) 2.1 AA compliance. WCAG 2.1 AA is the international standard for web accessibility compliance. This process was a cross-functional collaboration between design, product, and engineering. Even when we reach compliance, we’ll continue investing in accessibility to make Brightline as accessible as possible for as long as we’re shipping new features.
Josh Saint Jacque (he/him), a Senior Software Engineer, and Michelle Matthews (she/her and they/them), Director of Product Design, reflect on how accessibility shapes their roles here at Brightline and how they see their work delivering on our mission to serve kids, teens, and families.
Q: What are some ways your role impacts accessibility at Brightline?
Michelle: At Brightline, our mission is to provide quality care to every child that needs it. That should hold regardless of their levels of ability, and it’s something we prioritize as a team, so accessibility and inclusivity are core principles of our design team and process. We’ve conducted design accessibility audits and helped lead some of the WCAG 2.1 AA compliance work. We’re constantly iterating on our design system to ensure it’s accessible as well.
Josh: In order to provide care to as many families as we can, the engineering team considers how people of all abilities will be able to use the tools that our application provides. From determining what kind of care is right for them to finding the content that’s most helpful, every step has to work well even when a mouse isn’t the way families are interacting with what we build.
Q: Why is accessibility an important part of your role?
Michelle: As human-centered designers, I consider it a central part of our role to think about the many possible ways someone may be using our product and ensure we optimize for those experiences. We’re in many ways advocates. It feels like the right thing to do.
Josh: Modern development tools make building software faster than ever before. Unfortunately, that also makes it easier to ship features that are broken for people using assistive technologies, like screen readers, or who cannot use a mouse. While the basic technologies of the web “just work” when built with some fundamentals in mind, the ever-increasing complexity of the interfaces we build today means engineers have to carefully consider how people of all abilities will be able to navigate our applications.
Q: How do you believe your team’s accessibility work will impact Brightline’s members?
Michelle: I want all Brightline members to feel welcome and like they are equally considered in our product. If thoughtful alt-tags or easy-to-navigate screen reading of a website helps someone feel that way, even if they’re not the largest population we serve, I know we’ve done our work. I believe that will lend to them trusting our ability to provide care more and will help them find relief faster. It’s all part and parcel of our mission.
Josh: Our families navigating disabilities will be able to get the help they need without frustrating roadblocks due to accessibility issues. And all our families will enjoy a smoother, more intuitive experience thanks to some of the fundamental practices that building accessible software requires.
Q: What words of wisdom would you share with other teams looking to center accessibility more in their product development?
Michelle: I’ve worked for a number of companies that had the best intentions and yet still viewed accessibility as an oversight. It was something we’d eventually get to. And guess what? We never got to it. And if we tried, we’d be buried in design and tech debt that made accessibility feel impossible. If you’re at the beginning of a product, start this investment immediately. Bake it into your heuristics and design system. If you’re joining an established product, don’t be intimidated. Where can you start? Break it down by tasks. Any incremental improvements will be beneficial and will add up over time.
Josh: Accessibility doesn’t have to be hard. It might seem daunting when you’re first starting out, but we have better tooling and resources available than ever before. Many tools today integrate directly into our integrated development environments, web browsers, and continuous integration pipelines. Whether you’re just starting a project, or working on a large application, you can take small steps that will make your application easier to use for people with disabilities. Grab a popular screen reader and start testing the software you ship. Make sure you can navigate your application using only your keyboard. If you have a quality assurance team, work with them to integrate accessibility testing into their processes. One step at a time and eventually you’ll have a highly-accessible application, but you have to build values into your team that lead to these habits in the first place.