Accessibility Day: Making League a better, more inclusive product
When a company is just starting, it’s a race to make an idea a reality – to be the first to market and beat out the competition. Because of that, accessibility tends to fall by the wayside.
As you start to scale up, the things that were fine when you were a startup with few customers become a competitive disadvantage.
Product development teams have learned that accessibility can’t simply be a line item in feature estimates or story points added to a sprint. Accessibility considerations, optimizations and testing have to be embedded in the way we design and develop products.
Our team at League is aware of this, and we needed to own up to all the times accessibility has fallen off our radar. We wanted to make up for lost time.
After joining League as a Sr. Product Designer one of the first projects I worked on was an accessibility audit of our mobile apps with a focus on improving the experience for League members with visual impairments. Our mobile developers prioritized improvements to the way Screen Readers “read” our apps through built-in features like VoiceOver on iOS and TalkBack on Android (shout-out to Kelvin, Gourave and Miloš). It was exciting to see the team taking steps to ensure that our member-facing product was more accessible for people who are blind or visually impaired.
It was a testament to our team’s empathy for our users and a clear sign of our willingness to do better. We understood our responsibility as designers, developers, and creators of digital technology to build experiences that can be enjoyed by everyone.
Instead of ‘move fast and break things’, we’ve entered the era of ‘move thoughtfully and fix things.’
Most startups, in their early days are prone to following Facebook’s mantra of “move fast and break things.” There are deadlines to hit, features to deliver, and one of the things that is usually pushed to the background is accessibility. But as a health and benefits company, we have a mandate to be as inclusive and accessible as possible for the widest variety of users. As we grow, the number of users with disabilities using our product is also growing, and it’s clear to all of us that we can and should improve our products’ accessibility.
Tackling color contrast issues
As part of our shared focus on improving our product’s quality, one of the design team’s objectives for the quarter was to reduce the number of accessibility issues on the visual layer. We started by focusing on one of the Web Content Accessibility Guidelines’ (WCAG) main principles: perceivable.
Perceivable — Information and user interface components must be presentable to users in ways they can perceive. This means that users must be able to perceive the information being presented (it can’t be invisible to all of their senses)
There were many ways we could have done this, but we decided to focus on reducing the amount of color contrast issues. According to the WHO, approximately 1.3 billion people live with some form of vision impairment, and large percentage of these people suffer from decreased sensitivity to certain colors and contrast.
Once we decided where to focus, we ran an audit of our Web, Android and iOS platforms (using Chrome’s DevTools accessibility features and Stark, a color contrast analyzer for Sketch) and came up with a list of about 30 high-priority issues that we needed to address.
Our next step was to sit down as a team and discuss the best approach to tackle these issues. During one of our planning meetings, we analyzed our options and created an accessibility roadmap. We framed the discussion around two main approaches:
- Make one of our one-week sprints dedicated to accessibility
- On an ongoing basis, add accessibility tickets to our sprints.
In the end, we found that there were pros and cons to both those options, so we decided (as an experiment) to run a one day sprint dedicated to solving as many of these issues as we could.
Once we decided that this would be a full-day endeavor we created a small but mighty cross-functional team. This team was composed of a Front-End Developer, an iOS Developer, an Android Developer and a Product Designer. We booked a war room for the whole day, put on a funky playlist and got to work.
Accessibility Day sprint playbook
1. List and discuss all the issues
We listed all the issues that were discovered during the audit by platform, screen and element affected. As we were going over those issues we were also discussing some possible fixes and solutions.
Some of the main issues were:
- Four UI colors (used in buttons, text links, text and error messages) didn’t comply with WCAG contrast ratio guidelines
- Overlaying text on images without proper color contrast
- Not enough contrast on the users’ default avatar
- Notification badge also had a low contrast ratio
2. Create and prioritize tickets
Once we reviewed the issues, the team created post-its for each task. This allowed us to visually track the priority and completion of the issues, and was a less cumbersome approach than using JIRA or Trello. This also allowed us to understand the effort required to complete each task. We then discussed the best way to prioritize the tickets, in a High Impact / Low Effort matrix style: which tickets will have the highest impact on our product and require the least amount of effort.
3. Start a Kanban board
After creating and prioritizing the tickets, we quickly realized that the best way to track progress and keep our work visible to the other team members was to create a Kanban board. Since our office is new and we didn’t have whiteboard walls at the time, we drew a Kanban board on our glass window, which made it a bit hard to read (ironic, right?) but still got the job done.
4. Solve problems on the go
As the designer on the team, my role was to support the developers with solutions for the issues that we found. Most of them were very simple and focused on the perceivable principle, like changing the button text color to a color that met the W3C guidelines of 4.5 to 1 contrast ratio (conformance level AA.). To do this, I used Stark– a color contrast analyser for Sketch that has become a regular part of our design process.
Others were a bit more complex, however, like our ‘Create Account’ or ‘Sign in’ screens. This is where it really came down to team collaboration. We all contributed to the solutions and helped with quality assurance (QA) along the way. We documented the decisions being made as we went in order to ensure that all platforms were addressing the issues in a consistent way.
5. Review and Debrief
Our sprint day ended at around 5 p.m. We wrapped things up with the developers showcasing their completed features. We also reviewed all the work that was done for each platform to ensure consistency. We also discussed some learnings from this day, what worked and what didn’t, and how we can improve this process for our next sprint.
Learnings from the sprint
From the debrief, it was unanimous that the sprint had been a success. We were able to solve around 75% of our known color accessibility issues, and uncover new ones to add to the roadmap. We also really enjoyed working together in a cross-functional team and collaborating closely. Most importantly, we were proud to make a significant improvement to our product that resulted in a better experience for everyone.
But it being a success doesn’t necessarily mean that everything was perfect. There were some key takeaways on what we could do to improve:
- Have designs ready before the sprint for the most challenging issues
- Run a scoping and prioritization session prior to the sprint to leave more time for development
- Upfront definition of how we will measure success for these improvements
- A fast-follow plan to test these improvements with our target users (so they can be the judge of whether we were truly successful!) For example, scheduling interviews with low-vision users to test our new login page.
How can we be better?
After the sprint we shared the results with the broader product team and the reaction was very positive. But one of the questions that was raised was “how can we prevent these band-aid sprints from being needed in the first place?” There are ways to avoid having to fix accessibility issues downstream, and these start with making accessibility a core part of our design and development processes.
The TL;DR of our learnings:
Accessibility can’t simply be a line item in feature estimates or story points added to a sprint. Accessibility considerations, optimization and testing have to be embedded in the way we design and develop products. Every day.
Here are some of the steps that we are taking to decrease the number of accessibility issues:
- Making Accessibility one of our core design principles
Communicating to the team the importance and the value of designing with inclusivity and accessibility in mind - Ensuring all our design system elements are accessible
As we build our design system, every element and state needs to follow accessibility standards (WCAG 2.1) - Add Accessibility QA (Quality Assurance) to our “Definition of Done”
Testing for accessibility to be added as part of the acceptance criteria for any user story completed in a sprint - Create Accessibility personas and post them on the walls of our office
Creating artifacts that are posted up on the walls of our office keep these personas top of mind. Here’s an example of how we’ve created accessibility personas for people with a range of disabilities, from visual and auditory impairments to motor skills.
Conclusion
Designing for accessibility can be tedious and therefore is something often ignored, especially if the people designing and building these products are not the ones that have a disability. The truth is, most likely, that won’t always be the case.
“We’re all just temporarily abled.” — Cindy Li
Let’s design and build for the future you. Let’s think about everyone that is using our products. Let’s make our technology easy to use for all people, regardless of their abilities. And don’t worry about it not being perfect, it doesn’t have to be. Just make your products a little better than yesterday, and talk to the people you’re building for. You have that power.
