Context
Moxo (formerly Moxtra) is a business-to-client collaboration platform that helps manage client relationships by providing a powerful and fully branded mobile and web application. I was tasked with helping meet AA compliance within one month after it became critical to close a large deal for the company.
Although our more recent designs had started using a design system and color variables, we could not significantly improve their accessibility due to brand and scope constraints. Additionally, most of our app was built without designers over 8 years ago, which made matters worse. This meant that I would need to work closely with engineers to develop a solution that minimally impacted the legacy codebase, maintained the integrity of recent feature releases, and met compliance guidelines within the tight one-month timeframe.
My primary focus was on two aspects of WCAG AA compliance: ensuring adequate color contrast (1.4.3, 1.4.11) and avoiding using color alone to convey important information (1.4.1). Because this task had a short deadline and several other engineering-intensive action items, the design solution had to be as simple as possible.
Improving Color Contrast
My first priority was to discuss possible approaches with engineers to resolve the color inconsistencies in our older features. Initially, we decided it would be easiest for engineers to provide a spreadsheet of all color properties from the legacy code so I could map them to our existing color variables, which could then be updated to ensure guidelines were met.
After receiving the spreadsheet, however, I was shocked to find over 600 mostly unrecognizable color values to parse. Without any contextual information on where or how they were being used, I instead used the web inspector to hunt down these values individually, finding their usage and assigning them to a corresponding color variable. Each night, our China-based front-end web developer would implement the changes, using “find and replace all” on the color values according to the list I had compiled during the day.
This sped up the process for both of us by dramatically reducing the number of repeated colors for me to document and the number of values for the engineer to replace. Predictably, this process occasionally resulted in certain UI elements having incorrect colors applied. Fortunately, most of these misapplied variables were easy to spot through a quick page review, enabling me to note the correct values for adjustment the following day.
After ensuring the majority of the app used our semantic color variables, the next step was to update the color variables to be compliant. I started by collecting common patterns across our app to understand all of the scenarios we had used our label, fill, and status colors and which combinations we would need to ensure met the AA guidelines.
For example, we often place our “positive” green color variable on top of a 10% opacity fill of that same color. I set up a document to test all the combinations observed and then worked to find colors that passed for each case while maintaining a similar feeling and visual weight to our original colors.
The most challenging part of defining these new colors was ensuring that the new greyscale label and fill properties retained the same visual weight as the previous values.
In order to meet the contrast requirements, all values had to be darkened quite a bit. However, if they were too dark, the visual design of some components and page layouts became less appealing. It was also essential that the differences in lightness between the primary, secondary, tertiary, and quaternary values felt consistent with the previous colors. Additionally, some component states relied on lighter colors to show they were disabled or deselected; if these became too dark, they would lose that clarity.
Eliminating Reliance on Color
In addition to adjusting the colors to meet contrast guidelines, I also had to review existing components and interfaces to ensure we were not using color as the only visual means of conveying information. Fortunately, since our product had generally been designed with custom branding in mind, most of our components and page layouts already complied with this rule naturally.
The biggest offender I found was our toggle switch component. Although there was a slight contrast between the on and off state when viewed in greyscale, it was definitely not enough. To resolve this using the least amount of engineering resources, I opted to add icons as a secondary way to distinguish the state of the toggle switch.
Results
By updating the legacy colors to the new color variables through a systematic review process, engineers were able to unify our app’s UI into one consistent color variable system in just three mornings.
This method helped us avoid several weeks of review, testing, and bug reporting from the design and QA teams, which would have been necessary with the initial plan of re-mapping each color individually. With our entire product unified under 12 colors, I was able to deliver the new values quickly, ensuring compliance with AA contrast guidelines.
This systems-level approach enabled us to meet contrast and color reliance guidelines well ahead of schedule within just one week. This efficiency gave engineers more time to focus on addressing code-level accessibility issues.
