Skip to content

Color updates in GitLab to establish an accessible baseline

Background

At GitLab, we want everyone to be able to contribute. Part of that is ensuring our UI is built with accessibility in mind. To that end we’ve been working on updates to our color palette with regards to satisfying WCAG 2.1 1.4.3 Contrast (Minimum).

Why is color so important?

There are many different visual impairments. It is estimated that about 4% of the population have low vision, and 7–12% of men experience colorblindness, while less than 1% of women do (Color Contrast And Why You Should Rethink It — Smashing Magazine). Color contrast can benefit everyone, but especially those with low vision. Likewise, choosing good color combinations and ensuring that color alone isn’t used to provide meaning benefits everyone, but especially those who cannot distinguish some color combinations.

Goals and challenges

Primary goals

  • Create an accessible, consistent baseline across all hues in the palette — ensuring that minimum contrast ratios are met in predictable ways.
  • Normalize the use of color variables. For example, an info alert that uses $blue-50 and $blue-600 has the same contrast as a warning alert that uses $orange-50 and $orange-600.
  • Consider how the palette will be used in light UI vs. Dark UI for future iterations.
  • Satisfy the WCAG 2.1 1.4.3 Contrast (Minimum) requirements.

Challenges

  • Orange and green hues, which we use extensively, are notoriously difficult to maintain their vivid quality when meeting contrast ratios. Increasing contrast for these hues also makes it tougher to distinguish red-green and orange-green color combinations, which impacts colorblind users.
  • Variables in GitLab SCSS sometimes override variables in gitlab-ui SCSS, but not always.
  • The prolific use of color, combined with dynamic content and feature-rich capabilities makes it difficult to test every scenario.

Where we are today

After months of effort, we completed the first step of updating color variables in the gitlab-ui project with this merge request (MR). This MR introduced many color-specific visual updates to the product, several of which are initially undesirable. GitLab styles (SCSS) and gitlab-UI styles are not the same thing, and in some cases GitLab styles override the latest styles in gitlab-UI, but in others they do not, which is why many of the new styles are ”bleeding” through. The sweeping change is not reflective of how we’d like the updates to occur, so in this MR we’ve allowed all gitlab-ui color variables to be overridden by GitLab styles by using the !default flag in the SCSS. This will lessen the visual changes by allowing GitLab to override new styles, until we can make a full code review to determine where overrides are happening and address case-by-case.

Next steps

  • Evaluating which components and areas of the UI are most impacted but the change, in other words, determine where styles are being overridden and where they aren’t.
  • Remap color variables for components and the UI. For example, the current orange palette skews lighter, so darker variables are used in some places to compensate. After normalizing the variables, we need to use lighter variables. The neutral palette also has to be remapped in many places.
  • Evaluate areas of the product where we could simply use color in better ways. For example, red-green colorblindness is one of the most common conditions, and we have many instances where actions and UI elements pair red and green next to each other. See this issue on the combination of red and green buttons for reference. Issues will be created to track changes under the Component and UI color changes post accessible palette update epic.
  • Update our VPAT to show a “Supports” status for color contrast.
  • Address all issues in the Accessibility: Color palettes and use epic.
  • Fully communicate all changes in a larger blog post.

If you’d like to contribute, please consider adding an issue to this epic &2964.

Edited by Jeremy Elder