.github/workflows
ci.yml +13 -2
deploy.yml +1 -1
deploy_preview.yml +1 -1
content
components
component-documentation-guidelines
component-documentation-guidelines.md +1 -1
data-table.mdx +1 -1
foundations
color.mdx +37 -37
typography.mdx +3 -3
ui-patterns
button-usage.mdx +2 -2
empty-states.mdx +1 -1
feature-onboarding.mdx +2 -2
forms.mdx +2 -2
messaging.mdx +1 -1
docs
content.md +1 -1
.markdownlint-cli2.cjs +19 -0
package.json +4 -1
yarn.lock +101 -10
+ 13
- 2
@@ -10,5 +10,16 @@ jobs:
+ 1
- 1
@@ -19,7 +19,7 @@ When documenting components, consider the core elements needed to convey its mai
+ 37
- 37
@@ -32,7 +32,7 @@ For example use `bg-default` for the background of the page and `fg-default` for
@@ -74,21 +74,21 @@ Foreground elements are **text and icons**. You can apply color to them by using
@@ -96,22 +96,22 @@ Background colors apply to surfaces of components or UI elements, such as pages,
@@ -119,20 +119,20 @@ Borders can be used to group content or to create a visible separation between s
@@ -29,19 +29,19 @@ We utilize system fonts at GitHub, which allow for optimized performance. This d
@@ -116,13 +116,13 @@ Buttons that only use an icon should still have a label that is invisible to sig
@@ -29,7 +29,7 @@ Blankslates can and are encouraged to use one primary action. This button should
Secondary actions are optional and are represented by a text link located below the primary action button. A secondary action is used to direct a user to additional content about the feature. This might look like "[Learn more about X](#)" or "[Check out the guide on X](#)" or simply "[Learn more](#)".
@@ -133,7 +133,7 @@ Treat feature onboarding as a story or a journey with a beginning, middle, and e
@@ -313,7 +313,7 @@ Use inline banners in a page with multiple steps or actions.
+ 2
- 2
@@ -35,7 +35,7 @@ A caption may be used to provide additional context about the field to help user
@@ -104,7 +104,7 @@ For more information about form validation, see the [validation guidelines](#val
@@ -60,7 +60,7 @@ Toasts should be brief and not bog down the experience with superfluous copy. If
Toasts are non-modal components and should contain `role=log`, which implies the element has `aria-live="polite"`. This notifies the user of the toast via Assistance Technologies without having to change focus to the toast. You can read more about `role=log` [here](https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA23).
Toasts are non-modal components and should contain `role=log`, which implies the element has `aria-live="polite"`. This notifies the user of the toast via Assistance Technologies without having to change focus to the toast. You can read more about `role=log` at [W3: Using `role=log` to identify sequential information updates](https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA23).
Toasts are generally informative and should not receive focus when they appear. For that reason, we suggest you **avoid using interactive elements** in the component (aside from a dismiss action). Keep in mind that, even without an explicit dismiss action, the user can always hit `esc` to dismiss the toast. For more information on how interactive children affect web accessibility, [check out this issue](https://github.com/jackbsteinberg/std-toast/issues/29).
I upgraded the
node_version
for compatability withmarkdownlint-cli2
node dependency. I sawci.yml
already usesnode_version: 14
so assuming this is fine but let me know otherwise!