Checked all the colors to contrast between different colour combinations against WCAG 2.1 standards. Compared of the contrast the foreground and background of the elements that are in the page according of the Web Content Accessibility Guidelines (WCAG).
Contrast is calculated using “relative luminance”, which is defined as: The relative brightness of any point in a colorspace, normalized to 0 for darkest black and 1 for lightest white. The relative luminance can be calculated from any colour code (like HEX or RGB).
Checked all the color to contrast between the foreground and background of the elements that are in the page according to the WCAG 2.1.
Select from different WCAG rulesets to scan your site against. Choose from WCAG 2.0 A, WCAG 2.0 AA, WCAG 2.1 A, WCAG 2.1 AA, or best practice, and analyze your results. You can highlight their location on the page, expand details, and view their severity.
Select the foreground and background color of any elements on the page to check their contrast ratio and WCAG conformance.
The features of Contrast Grid are quite clear and easy to use. All you have to do is input the colors’ names or HEX values into the Rows and Columns box on the left side of the tool. You can choose to use the same values for both background (rows) and text (columns), or use distinct options by entering the values separately on each box.
One thing to note when entering the HEX values is that you have to enter only one color per line. Alternatively, you can input optional color labels in addition to their values by separating them with a comma.
As soon as your input is done, your choice of colors will be automatically displayed on the grid. You can see different combinations of text and background colors along with their WCAG accessibility grades and contrast ratio.
Do pay attention to the highlighted grades. Most of the time, the grid will show the following grades:
In addition to those main features, Contrast Grid provides a tile size option to adjust the size of your text. You can also copy the Grid HTML/CSS into web-based documents and share it with other collaborators.
We then listed all the combinations that needed more contrast and proposed new colors to meet the minimum.
These are just a few examples of the proposed changes.
In order to keep a consistent selection of shades from the same gray hue, we realized that we needed further changes to the palette. So we ended up changing two other tones and getting rid of one, since a darker starting point meant less noticeable variation.
We proposed several other changes on the complete grayscale palette, like getting rid of colors, defining which colors could be used with a light or dark background or changes in names.
Once we began the implementation planning process, we realized how much overhead all these small changes added and how long it would take to implement them on all our product, websites, and other marketing graphics. We then decided to scope it down and came up with a second proposal.
This new one kept the changes to the darker grays but didn’t remove any color or change any name — it maintained unnecessary colors and inconsistent names but solved our accessibility concerns with a time investment we could afford.
Purple 3 and Malibu use Tachyons framework and utility classes to build GUIs flexibly while maintaining consistency. We propose a new color palette that requires rigorous auditing before releasing to customers. We use Review Apps, a platform built for this purpose, to automatically generate a review app containing new production-ready CSS and SVG assets on a dedicated URL.
This allows easy auditing of the new color palette in a review app that can be swapped in with a pull request.
It’s not always easy to predict how the components of a design system will end up being combined in practice, especially in a large app with many features added over many years. We had to ensure we were improving the legibility of common elements such as form labels, notifications, and warnings, but also more exotic elements such as our metrics charts.
For the most part, we were very happy with how the improvements worked in practice and were even happier to see the number of color contrast violations in our GUIs drop by an order of magnitude. Straying slightly outside of the proposed new grays, we discovered that finding a shade of orange that met our standards for contrast, legibility, and aesthetic elegance was surprisingly challenging!
Once our teams had taken the time to audit each of our GUIs and we were confident we hadn’t regressed legibility in any areas, we rolled out the change to customers. In the end, a mix of solid research, theory, tools, and attention to detail got us to where we wanted to be—a GUI that is every bit as elegant as before but now markedly more accessible.
Note: The numbers here are adjusted to include an element that is currently not audited accurately by axe-core. These numbers are not universal, but are a fairly accurate representation of using method with an average number of apps and entities displayed.
The new color palette has been rolled out across all of the Dashboard. When you visit any page in the Dashboard, you will find improved color contrasts that are a result of the work that has been done. While it can be hard to discern the improvement in legibility from one day to the next, the impact is much easier to spot when looking at the before and after interfaces side-by-side.
Below are two identical screenshots of the Spaces section of the Dashboard with the old colors on the left and the new colors on the right. Note the darker gray (1) and blue (2) text.
It’s not always easy to predict how the components of a design system will end up being combined in practice, especially in a large app with many features added over many years. We had to ensure we were improving the legibility of common elements such as form labels, notifications, and warnings, but also more exotic elements such as our metrics charts.
Color Contrast tools— https://www.chhs.colostate.edu/accessibility/best-practices-how-tos/color-contrast-tools/
W3 — https://www.w3.org/WAI/test-evaluate/preliminary/#contrast
Easy Checks – A First Review of Web Accessibility — https://www.w3.org/WAI/test-evaluate/preliminary/#contrast
Web Content Accessibility Guidelines (WCAG) 2.0 — https://www.w3.org/TR/WCAG20/
Designing for Accessibility: Contrast Ratio — https://blog.heroku.com/designing-for-accessibility-contrast-ratio