Button color, meaning, and accessibility
Problems
- Some components, like alerts, use the primary info variant (blue), while other parts of the UI, like issuables or empty states, use the primary success variant (green). Neither case fully or always aligns with color meaning defined in Pajamas.
Blue indicates a current or active state. It communicates management, progress, connectivity, or organization. Green indicates success. It communicates save, create, add, available, done, approved, or resolved.
- Blue is used for everything for nearly all text links, and most of those actions fall under the green definition. Several green buttons could be seen as progress or other items under the blue definition.
- The frequent orange/green button combination is problematic for users with red/green colorblindness (This is a really important one that won’t be solved with our current approach). In fact, the success, warning, and danger buttons all look similar with the most common types of colorblindness.
- Because we have to darken our orange to meet accessibility contrast, it is much closer to the red. This means that differentiating warning vs. danger is more difficult.
- We are making design decisions based on primary action and color meaning, sometimes these conflict with dynamic content (which is why we used the info variant for alerts, which felt like the most neutral option), and it adds a layer of nuance/friction to the decision making process.
Proposal
- Simplify our buttons by defining one primary solid button color to represent primary actions. The only exception would be a solid danger button.
- Use blue as the primary button color to solve for red/green colorblindness. A blue/red combination works for all types of colorblindness (with the exception of monochromacy where no color is perceived).
-
Use neutral borders for secondary buttons to a) feel more integrated in the UI, and b) let the text stand out more.Secondary button color applies to the border and the text. - Focus more on the level of the action, not the meaning of the action.
- Use danger buttons only for potentially destructive or negative irreversible actions (like deleting, removing, etc.). Closing an issue isn’t destructive, for example, because it can be reopened.
Benefits
- Allow color to have more value by using less of it. This means that statuses, badges, and labels can be more independent without clashing with a bunch of button colors. This equals less visual clutter too.
- Less button colors means less opportunity for confusion with badges or labels.
- Accessibility! Let’s finally fix the red/green problem with our orange/green buttons. Let’s avoid having users pick up on the subtle difference between a warning and a danger button.
- Easier design decisions.
- Allows dynamically created actions to exist outside of meaning (with the exception of danger). In other words, a button could say “Configure settings” or “Learn more about CI/CD” and color doesn’t matter because it’s about being the primary action — we don’t have to know both the meaning (currently using color) and the hierarchy (primary vs. secondary).
- Performance: Each button style has 3 states (not including the universal disabled style), reducing variants reduces styles needed.
- Simplifies theming for dark mode.
- The color of actions aligns throughout the product — they are always blue, red, or neutral. This aligns buttons with text links, toggles, pagination, checkboxes and radio buttons.
- Orange is one of our brand colors, let’s not use it for a warning in this way (I realize it’d still be part of status).
Inspiration
Concepts
Current button set
- Default
- Default tertiary
- Info primary
- Info secondary
- Info tertiary
- Success primary
- Success secondary
- success tertiary
- Warning primary
- Warning secondary
- Warning tertiary
- Danger primary
- Danger secondary
- Danger tertiary
Proposed button set
- Default (neutral)
- Default tertiary
- Affirm primary (blue)
- Affirm secondary
- Affirm tertiary
- Danger primary (red)
- Danger secondary
- Danger tertiary
/cc @gitlab-com/gitlab-ux/designers @gitlab-com/gitlab-ux/ux-foundations @clenneville @ealcantara
Edited by Jeremy Elder