-
Notifications
You must be signed in to change notification settings - Fork 49
Update Color page on Helios website (Foundations section) #2870
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
e43c24d
Update guidelines.md
LilithJames-HDS 77e2d3e
Update guidelines.md
LilithJames-HDS df3a303
Update guidelines.md
LilithJames-HDS e5a48ae
Update to diagram
LilithJames-HDS 847ce8c
New image for naming
LilithJames-HDS 8051e7c
Added intro for element content
LilithJames-HDS 1a0a809
Text refinement
LilithJames-HDS 089e8be
Update overview.md
LilithJames-HDS 7e4e24d
Update guidelines.md
LilithJames-HDS 1a1e6cd
Update website/docs/foundations/colors/partials/guidelines/guidelines.md
LilithJames-HDS 9d51147
Update website/docs/foundations/colors/partials/guidelines/guidelines.md
LilithJames-HDS b60345f
Update website/docs/foundations/colors/partials/guidelines/guidelines.md
LilithJames-HDS 2fc2a61
Update website/docs/foundations/colors/partials/guidelines/guidelines.md
LilithJames-HDS 4cc478b
Update website/docs/foundations/colors/partials/guidelines/guidelines.md
LilithJames-HDS c033ffa
Apply suggestions from code review
LilithJames-HDS f9af13e
Update guidelines.md
LilithJames-HDS e339ff0
Merge branch 'lilith-colors-doc-revamp' of https://github.com/hashico…
LilithJames-HDS File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
74 changes: 43 additions & 31 deletions
74
website/docs/foundations/colors/partials/guidelines/guidelines.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,94 +1,106 @@ | ||
## Color styles and tokens | ||
## Color tokens | ||
|
||
Color-naming syntax and usage can vary depending on context and tooling. This overview will clarify what naming conventions are typically used and how they align with the HDS standards implemented in our libraries. | ||
Color-naming syntax and usage can vary depending on context and tooling. Semantic naming conventions within our system allow us to implement consistent standards in our libraries. | ||
|
||
In Figma, reusable colors are referred to as “Styles.” They are categorized and stored in the right sidebar for fills, borders, and other properties that accept color values. Styles directly reference a HEX value but cannot reference each other (known as aliasing for Tokens). This means when we provide Figma Styles for semantic usage (like `Foreground/Primary`), the HEX value (`#3B3D45`) is directly referenced instead of the Core Palette color (`Palette/Neutral/Neutral 600`). | ||
In Figma, we use Variables to define and organize color values. Variables allow us to create palettes that reference (or alias) each other. Our Core Palette is a collection of HEX values and their color ramps (`neutral-50`, `neutral-100`,...`neutral-700`). These values are then connected to Semantic Variables (`foreground-primary`, `surface-faint`, `border-critical`). This alias connection allows us to designate multiple token uses for individual HEX values that lead back to the same Core Palette token. | ||
|
||
In code, we refer to reusable colors as “Tokens.” They are generated from platform-agnostic files, in our case JSON, and create atomic colors regardless of what platform or framework is used. For example, Core Palette colors like `--token-color-palette-neutral-600` are directly referenced in `--token-color-foreground-primary`. | ||
Tokens in code are generated from platform-agnostic files, in our case JSON, and create atomic colors regardless of what platform or framework is used. Core Palette values are directly referenced in Semantic Palette values in the same way that Figma variables alias one another. | ||
|
||
 | ||
 | ||
|
||
## What are semantic colors? | ||
|
||
The Semantic Palette helps ensure proper color usage across applications by embedding meaning directly into the name. | ||
The Semantic Palette embeds meaning into color names, making it easier to select correct consistent values across applications. These colors are designed to meet accessibility standards when used in combination with one another. | ||
- Foreground colors are intended to be used with surface or page colors. | ||
- Status color values consist of "surface," "on-surface," and "high-contrast" options to meet accessibility standards when used together. | ||
|
||
Semantic colors were designed to be used together, ensuring they meet accessibility standards and look visually pleasing. For example, foreground colors are intended to be used with surface or page colors. In many cases, it is important to use specific contextual naming conventions, such as status colors, together. Here are some examples of semantic color combinations with their respective contrast ratios: | ||
Some examples of semantic color combinations with their respective contrast ratios are: | ||
- `Foreground/Strong` on `Surface/Primary` nets a ratio of 19.54:1 | ||
- `Foreground/Success-on Surface` on `Surface/Success` nets a ratio of 5.37:1 | ||
- `Foreground/Primary` on `Surface/Primary` nets a ratio of 10.82:1 | ||
- `Foreground/Action` on `Surface/Faint` nets a ratio of 4.86:1 | ||
|
||
 | ||
|
||
The **element** and the **role** are referenced in the name to help make more informed color decisions. | ||
### How are semantic names created? | ||
|
||
HDS organizes semantic tokens into **element** categories: | ||
In semantic token naming, the **element** and the **role** are defined to make color decisions easier and more consistent. HDS organizes semantic tokens into **element** categories with **roles** appended. | ||
|
||
- **Foreground** - For elements such as text, links, statuses, and icons. | ||
- **Border** - For borders on components, containers, or dividers. | ||
 | ||
|
||
Examples of **element** naming include: | ||
|
||
- **Foreground** - For text, link, status, and icon elements | ||
- **Border** - For borders (or strokes) on components, containers, or dividers | ||
- **Surface** - For the background (or surface) of a component or container | ||
- **Page** - For page backgrounds | ||
|
||
Examples of **role** naming conventions include: | ||
Examples of **role** in naming include: | ||
|
||
- Strong | ||
- Primary | ||
- Faint | ||
- Action (not to be used outside of context) | ||
- Disabled (not to be used outside of context) | ||
|
||
### Foreground colors | ||
### Foreground | ||
|
||
Foreground colors are used for elements such as text, links, and icons. | ||
Foreground colors are used for informational and decorative elements such as text, links, and icons. | ||
|
||
Some common examples of semantic foreground colors include: | ||
|
||
- `Foreground/Strong` for headings and secondary links | ||
- `Foreground/Primary` for body text | ||
- `Foreground/Faint` for less prominent text and UI elements. | ||
- `Foreground/Action` for primary call to action such as links | ||
- `Foreground/Faint` for less prominent text and UI elements | ||
- `Foreground/Action` for primary calls to action such as links | ||
|
||
 | ||
|
||
Use status foreground colors to help contextualize responses from user actions or to indicate status within a UI. These colors should be used sparingly and within the context of specific components like [Alerts](/components/alert#color), [Toasts](/components/toast#color), or [Badges](/components/badge#color). | ||
Status foreground colors contextualize responses from user actions or indicate status within a UI. These colors should be used sparingly and within the context of specific components, for example: | ||
|
||
- [Alerts](/components/alert#color) | ||
- [Toasts](/components/toast#color) | ||
- [Badges](/components/badge#color) | ||
|
||
 | ||
|
||
### Border colors | ||
### Border | ||
|
||
Some common examples of border colors include: | ||
Some examples of border colors include: | ||
|
||
- `Border/Strong` for secondary Button border | ||
- `Border/Primary` for Card border or divider | ||
- `Border/{Status color}` for Alert borders | ||
|
||
 | ||
|
||
### Surface colors | ||
### Surface | ||
|
||
Use surface colors for the background (or surface) of a component or container. | ||
Surface colors are intended to be used for the background (or surface) of a component or container. | ||
|
||
Some common examples of surface colors include: | ||
Examples of surface colors include: | ||
|
||
- `Surface/Strong` for the neutral Badge. | ||
- `Surface/Primary` for component containers. | ||
- `Surface/Faint` for the secondary Button. | ||
- `Surface/{Status color}` for Alert background. | ||
- `Surface/Strong` for the neutral Badge | ||
- `Surface/Primary` for component containers | ||
- `Surface/Faint` for the secondary Button | ||
- `Surface/{Status color}` for Alert backgrounds | ||
|
||
 | ||
|
||
### Page colors | ||
### Page | ||
|
||
Page colors are used for page backgrounds. HDS components do not use these tokens; however, we recommend `Page/Primary` as the primary background color and `Page/Faint` as a means to create a secondary level on the page for highlighting information, if necessary. | ||
Page colors are used for page backgrounds. HDS components do not use these tokens; however, we recommend `Page/Primary` for all standard page backgrounds and `Page/Faint` as a means to create a secondary level on a page if necessary. | ||
|
||
## Accessible color combinations | ||
|
||
We intend to be conformant with WCAG 2.2 Level AA requirements. In terms of color contrast, this means a luminosity ratio of 4.5:1 for normal sized text, and 3:1 for large text (commonly 22px). Further details are outlined on [WCAG’s understanding of Contrast (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html). By default, semantic color tokens provide accessible color combinations out of the box with their associated naming conventions, while using palette colors requires manual validation, especially if you plan to mix and match. As an example, if a color has a semantic status name in it, then other associated status colors will be accessible. | ||
We are conformant with WCAG 2.2 Level AA requirements. For color contrast, this means a luminosity ratio of 4.5:1 for normal sized text, and 3:1 for large text (commonly 22px). Further details are outlined on [WCAG’s understanding of Contrast (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html). | ||
|
||
HDS semantic color tokens provide accessible color combinations out of the box when used according to their naming conventions (`Surface/{Status color}`is compliant in combination with `Foreground/{Status color on surface}`). Using other color token combinations requires manual validation. | ||
|
||
It is important to note that we [do not recommend the usage of disabled elements](/patterns/disabled-patterns), especially isolating disabled colors out of context, as they are not accessible. | ||
|
||
### Using palette colors | ||
|
||
The Core Palette is available if semantic colors do not meet your needs. These styles are usage-agnostic, which can introduce challenges in consistently scaling designs but also allow more freedom and flexibility in color pairing. | ||
If Semantic tokens do not meet your needs, the Core Palette is published for general use. These values are usage-agnostic, which can introduce challenges in consistently scaling designs but also allow more freedom and flexibility in color pairing. | ||
|
||
When pairing colors from the Core Palette, ensure adjacent colors meet accessible contrast ratios. To validate your color combinations, use free tools like the [WebAIM contrast checker](https://webaim.org/resources/contrastchecker/) or [Stark’s Figma plugin](https://www.figma.com/community/plugin/732603254453395948/stark-contrast-accessibility-checker). | ||
When pairing colors from the Core Palette, check that adjacent colors meet accessible contrast ratios. To validate your color combinations, use free tools like the [WebAIM contrast checker](https://webaim.org/resources/contrastchecker/) or [Stark’s Figma plugin](https://www.figma.com/community/plugin/732603254453395948/stark-contrast-accessibility-checker). |
2 changes: 1 addition & 1 deletion
2
website/docs/foundations/colors/partials/guidelines/overview.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1 @@ | ||
When choosing what colors to use, we recommend starting with semantic colors as their usage is clearly defined and common color pairings are accessible out of the box. | ||
When choosing color values in design, we recommend starting with semantic color tokens — values with clearly defined intent — and relying on color pairings in Helios that are accessible out of the box. |
Binary file added
BIN
+36.6 KB
website/public/assets/foundations/color/colors-semantic-token-naming.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified
BIN
-14.1 KB
(78%)
website/public/assets/foundations/color/colors-what-are-semantic-tokens.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great, concise breakdown! 👏