Building an accessible dark mode and high contrast mode in Quip
Leading the design for Quip's #1 feature request, prioritizing accessibility above all
Role
Design lead
Time
2021 (5 months)
Tags
A11y, colorwork, components
Intro
Colorblindness impacts 8% of men and 0.5% of women around the world. Even more people experience other vision impairments that would make low-contrast or exclusively light interfaces challenging to use.
Though dark mode was a long standing customer feature request, this project came onto our plate as primarily an accessibility concern. Quip’s existing interface was not only stark white, but also uneasily subtle (color-wise). The selected states and editing icons had abysmal color contrast ratings, the fonts leaned far on the too small side, and the primary colors only barely passed minimum accessibility requirements.
We approached this project first and foremost with the Web Content Accessibility Guidelines (WCAG) 2.1 in mind. Our objective was less to address customer desires as it was to accomodate users who might find it physically frustrating to function in a light interface. In this sense, our priorities ossified at a very early stage: create a UI that addresses all variations of the human vision outside of cosmetic preference. What resulted was an overwhelming need for, not aesthetic themes, but inclusory design. In this respect, we quickly realized that dark mode was only the first step in assisting our visually impaired users. We needed something slightly more dramatic—like a high contrast mode.
Getting an AA in WCAG 2.1
The Quip color palette was previously optimized for achieving an A rating, meaning, our palette was passably accessible, but not ideally accessible. You might compare this with getting a B on a test verses getting an A. To be sure, an A rating is comfortably sufficient for the majority of users, but for the remaining users, we knew that anything less than an AA grade for the most pertinent areas in the UI was unacceptable. In initial explorations, we briefly considered overhauling the existing palette to attain an AA schema, but quickly realized that this severely limited the colors we could use. It was virtually impossible to meet AA guidelines without compromising Quip’s product identity.
Hypothesis & metrics of success
We thus decided to approach this project in two prongs: first, establish a standard light and dark mode that met strict A accessibility requirements. Second, establish a high contrast mode that met strict AA accessibility requirements. We found this to be philosophically preferable to building a half-complete AA theme.
Our metrics for success for high contrast mode were clearly delineated for us in the WCAG AA guidelines. In the simplest terms, we based our color contrast goals on the size and the function of the element in question. Larger texts (18px or 14px bold or greater) and non-decorative UI/graphical elements needed to meet a 3:1 color contrast ratio against their background. Smaller text elements needed a more severe 4.5:1 ratio. Most importantly, we had to ensure that nothing in the product relied solely on color to convey information or state changes, regardless of how stark the color contrast might be.
Our metrics for success for high contrast mode were clearly delineated for us in the WCAG AA guidelines. In the simplest terms, we based our color contrast goals on the size and the function of the element in question. Larger texts (18px or 14px bold or greater) and non-decorative UI/graphical elements needed to meet a 3:1 color contrast ratio against their background. Smaller text elements needed a more severe 4.5:1 ratio. Most importantly, we had to ensure that nothing in the product relied solely on color to convey information or state changes, regardless of how stark the color contrast might be.
.png)
Uncovering problem areas
The Quip color palette was previously optimized for achieving an A rating, meaning, our palette was passably accessible, but not ideally accessible. You might compare this with getting a B on a test verses getting an A. To be sure, an A rating is comfortably sufficient for the majority of users, but for the remaining users, we knew that anything less than an AA grade for the most pertinent areas in the UI was unacceptable. In initial explorations, we briefly considered overhauling the existing palette to attain an AA schema, but quickly realized that this severely limited the colors we could use. It was virtually impossible to meet AA guidelines without compromising Quip’s product identity.
Turning the tables into dark mode
The first actionable step we took was to prime the field for adjustable color schemes. This meant we needed to retire constants with hardcoded color values, as a given color may not work equally well in both light and dark mode. Instead, we implemented CSS custom properties/variables which would adjust their colors depending on which color scheme the user has selected.
When researching dark mode color theory, we found that muted primary colors were necessary to reduce eye strain, but might deviate from Quip’s existing product identity. We experimented with variations of hex inversions, hue rotations, and HSL adjustments to strike what we considered to be a sufficient balance, all the while maintaining a minimum AA color contrast rating. Taking a formulaic approach to the color palette allowed us to turn our 80+ colors (12 derivative hues for each primary color plus neutrals) into a dark mode compatible palette.
When researching dark mode color theory, we found that muted primary colors were necessary to reduce eye strain, but might deviate from Quip’s existing product identity. We experimented with variations of hex inversions, hue rotations, and HSL adjustments to strike what we considered to be a sufficient balance, all the while maintaining a minimum AA color contrast rating. Taking a formulaic approach to the color palette allowed us to turn our 80+ colors (12 derivative hues for each primary color plus neutrals) into a dark mode compatible palette.
The 80+ scale of our palette allowed us systematically increase or decrease the saturation of the semantic colors depending on the mode we were in. We used this to our great advantage when establishing high contrast mode. For instance, the color that filled the role of --primaryBlueUI may represent a hue of blue 6 in our standard light and dark mode palettes, but we could easily bump this to be blue 7 in high contrast light/dark modes if that better fit AA standards.
This solution helped us quickly address a large portion of the 73 color contrast problem areas in a virtually automatic way, but still afforded us the flexibility to “hand pick” a value from the generated palette if we found a color to be insufficient.
This solution helped us quickly address a large portion of the 73 color contrast problem areas in a virtually automatic way, but still afforded us the flexibility to “hand pick” a value from the generated palette if we found a color to be insufficient.
.png)
Fine tuning for high contrast
Of course, this formulaic method was not without its flaws. While it may have addressed the majority of contrast concerns, it did not acknowledge some of the nuances in the WCAG fine print: namely, that we could not use only color to denote a state change in a UI. This issue materialized most vividly in our home navigation. Initially, I experimented around with symbolic indicators such as lines, rounded corners, and dots, for selected states. None of these appealed as appropriately high contrast enough. The line indicator was tough even for the non-visually impaired eye to make out.
Eventually, I realized that using negative space was just as powerful as using a large symbolic indicator. This change was discernible even to the fully colorblind eye and was easily transposed in other parts of our UI (which may or may not have had the space to accommodate a symbol).
Making it personal: settings
Deciding how users might access dark mode and high contrast mode was a slightly tricky problem. On one hand, moving these preferences into the appearance tab would make quite a bit of sense (as both have to do with appearances). On the other hand, we had just created a dedicated tab for accessibility settings, which would fit high contrast mode nicely. It wasn’t necessarily conveyed to users that high contrast mode was an accessibility feature if we decided to place it in the appearance tab. We very briefly toyed with the idea of including high contrast mode in both the appearance tab and the accessibility tab but realized quickly that this would only serve to confuse users. At the end of the day, we much preferred that users who needed high contrast mode the most knew where to find it.
Shipping
The launch process was just as iterative as the design process. Via the feedback of our wonderful internal testers, we were able to uncover several corners of the UI that our formulaic approach had not reached. I cannot emphasize enough the vigilance required to implement such a sweeping feature. Though, with every one inconsistency pointed out to us, there were ten moments of delight. Whats more— these were primarily for high contrast mode.
Working within the purview of our existing palette may or may not have been the correct move. We could have taken Stack Overflow's approach and simplified our perhaps too large palette. Though I should note that the algorithmic approach would probably not have worked if our palette were smaller than it were. In future iterations I would absolutely love to take a closer look at the color palette, not just to simplify it but to push the primary colors from A grade closer to AA.
Working within the purview of our existing palette may or may not have been the correct move. We could have taken Stack Overflow's approach and simplified our perhaps too large palette. Though I should note that the algorithmic approach would probably not have worked if our palette were smaller than it were. In future iterations I would absolutely love to take a closer look at the color palette, not just to simplify it but to push the primary colors from A grade closer to AA.
.png)