How we’re creating inclusive and accessible products for ALL families
Fortunately, it's no longer a controversial statement to say that products should be built with accessibility in mind as an initial requirement—and not as an afterthought.
Our goal at Brave Care is to help every child reach their full potential. Our amazing clinic staff work day in and day out to provide the best care experience for our Brave Care families with patience, sound judgement, and incredible kindness. I'm a member of our product team, comprised of product managers, designers, researchers, and engineers who are all working to support our clinic team. We're responsible for developing new features and tools for our staff, patients, and their families.
No matter what team they sit on, each Brave Care employee is charged with living up to our values, some of which include "deeply empathize," "make every interaction count," and "advocate for others." And where the product team is concerned, a key way to live up to those values is to think about making products as inclusive and accessible as we can.
Fortunately, it's no longer a controversial statement to say that products should be built with accessibility in mind as an initial requirement and not as an afterthought. There are a number of helpful people and organizations who have focused on creating open source guides and sharing resources to meet any person working on a digital product (be it a product manager, designer, or engineer) where they are on the journey to creating accessible products. At the bottom of this post, I've included a collection of resources that I've found helpful.
At Brave Care, we’ve utilized many of those resources to ensure that accessibility remains top-of-mind. Here are a few recent examples:
1. Cindy, our Senior Manager of Brand, introduced new, higher contrast colors to our design system that meet the 4.5:1 ratio as required by the Web Content Accessibility Guidelines. Here’s what Cindy had to say about the process:
“Designing a brand for kids and families, we wanted a colorful brand language that was attention-grabbing and loved by both our primary audiences: the kiddos we serve and their caregivers. We went with a vibrant and sophisticated palette of bright accent colors and their pastel counterparts. After applying the colors to digital design (web and products), we quickly realized we needed to reevaluate the bright teal we’d selected for our buttons to be accessible for populations with vision impairments.
We set out to meet, or exceed WCAG 2.0 AA color contrast levels, which means color contrast needs to be a minimum of 4.5:1 ratio. Our teal button with white text was 2.44:1, far below the minimum (womp, womp). After reevaluating, we created a UI-specific teal color that now exceeds the minimum at 4.72:1. We also introduced a darker secondary color for use on pastel-colored backgrounds.
We aim to serve any family who needs care for their kiddos. That means our designs and colors should be accessible to ALL.”
2. As part of our design system implementation efforts, Ryan, our Senior Software Engineer, made sure that the text component in our check-in app was built with internationalization in mind. In this context, internationalization means a way of writing software that can be adapted to various languages and regions without requiring major engineering changes. All of the text used in the check-in app is currently translated into two languages (English and Spanish). At the beginning of every visit, each family has the opportunity to choose their preferred language before filling out the questions listed in the check-in app. We also offer translation services available for people who’d prefer another language. In the future, we’ll be adding support for more languages—and because the internationalization framework is already in place, our engineering team won’t have to be heavily involved once we translate the text.
3. We seek to use inclusive language in our check-in app and online scheduling forms. For example, we know each family has a unique composition, so we use the term “caregiver” to describe an individual who’s accompanying a patient to an appointment. From there, they’re given an opportunity to explain their relationship to the patient, again using inclusive language. Similarly, we know that it can be uncomfortable, especially for nonbinary and trans individuals, to be faced with another form that asks for their sex assigned at birth. We collect that information for insurance purposes, so we note that in the form to explain why it’s a required field. For similar reasons, we also ask for the name a patient goes by, and their pronouns with a dropdown that includes an option for a free form text field.
4. Noah, our Head of Product & Design, was tasked with coding new HTML email templates and made sure to research accessibility standards for that medium. It’s a challenge to get emails to both look consistent and be accessible in all sorts of different email clients. For example, the way the iPhone Mail app renders an email is not the same as the way Microsoft Office on a Windows desktop does. And usually there’s an influx of tables required to make layouts consistent across the wide variety of ways people read email. Many of these texts do not contain content and instead are required for structure, so it’s important to instruct screen readers to skip over them. We include images in our emails, so it was necessary to provide alternative text that describes the imagery so context is not lost for people using a screen reader or for those who have images turned off as a system preference.
Our work continues.
There’s always more improvements we can make to ensure we’re building accessible products. Here’s an outline of what we’re aiming to accomplish, and if you have any suggestions, please reach out to our Product Team at: firstname.lastname@example.org.
- Write and publish an accessibility statement.
- Ensure each new design system component meets accessibility guidelines and where possible, write unit tests to confirm.
- Create a formalized checklist for each member of the product team, so that new features start with accessibility in mind and are audited as such.
- Explore how automated testing can help catch common errors and implement it.
- Share more resources with teammates and celebrate their wins.
- Conduct user research across a wide audience, including people with cognitive disabilities and who use assistive devices.
- The A11Y Project (a11y stands for accessibility)
- Developing an accessibility statement
- No mouse days and Marcy Sutton's course on front-end masters
- Animations as a progressive enhancement
- Accessibility at Vox checklist
- The most useful accessibility testing tools and techniques
- CSS tricks’s accessibility archive
- Designing for cognitive disabilities
- HTML Email and Accessibility
- Get Stark