Insights from adding accessibility: colo ...

Insights from adding accessibility: color contrast to Nucleus

Jun 12, 2021

Our first goal in adding accessibility in the Nucleus is working on the contrast. We audited all the components we have, and we found that some of the components didn't pass the AA. It's not an easy job, really. We tested it back and forth and gained some other insights from big companies' design systems such as Atlassian, Google Material, inspected app that supports dark mode and large user base. This journey helps us to rethink the process of building design systems from the ground up.

Here's one of the lessons learned we got so far:

We found that AA is the balance between aesthetic and accessible.


If we push our design to be AAA, it will break the aesthetic to some degree. Still, it depends on the foundation (colors and typography) of your product too. If your product is simple with monochromatic, doesn't have much content on one screen (imagine an Apple Watch), I think it's way simpler to achieve AAA but still maintaining the aesthetic.

What if the case is we design a mindfulness app, like Calm. We have checked the contrast, and some of the elements are failed to achieve the AA level.

But if Calm passes the AA level, We think we wouldn't fall in love 😍 with the beauty and calming feeling of the app.

Does that mean some apps shouldn't care much about accessibility?


I'd say every product should care about accessibility.

However, different strategies and thought processes should be applied for different contexts, different apps. For example, in Calm, we can't directly apply what the contrast checker says.

  • Context comes first
    You can make constraints on what level, on which components, and in what context you will follow/ not follow the Accessibility rules based on WCAG. There are some apps that, even for a disabled button they make the text contrast enough. However, some apps not.

    In the context of the disabled buttons, We might bend the rules because we assume it's quite obvious it's a button, and since it's a pretty straightforward screen (a login screen), so I think it would be fine – It won't mislead users. However, we still need to check other contexts. We can put constraints on other contexts, not to use the disabled elements as we did in other contexts.

  • Allow users to adjust the font sizes (from phone settings) or enable a different contrast mode.
    I believe that no one size fits all, so that we enable users to adjust based on their own preferences.
    Our app should follow the font size system. It doesn't look good for us. But for some people, our dads & moms, it makes them easier to read without squinting.

    Or the other solution (with more effort absolutely) could be adding a contrast mode that changes the transparent background into a solid background, light-weight text into normal/book-weight text, and anything that makes the contrast much better.

  • Last, rethinking the design system from the ground up –
    but still conveying the general mood of the brand. It's not easy, though. Some people say, "Build an accessible product, not build a product that is accessible." Meaning, we put our thinking about accessibility from the beginning, altogether with aesthetics, when we design the visual of the product.

    What's your thought?

Credits to: Calm & Airbnb for their app screens

Enjoy this post?

Buy Nucleus UI a coffee

1 comment

More from Nucleus UI