Design Systems Checklist.

Vision.

Why you exist, what you believe in, and what direction you’re going.

Design Principles.

These are your go-to rules for making design choices. They help keep your work focused and clear.

Tone of Voice.

How you sound when you talk to users. This helps make sure people always know it’s you speaking, no matter where they are.

• WCAG:
• 3.1
• 3.1.1
• 3.1.2
• 3.1.3
• 3.1.4
• 3.1.5
• 3.1.6

Terminology.

Pick the right words and use them the same way across your product. This keeps things simple and clear.

• WCAG:
• 3.1.3
• 3.1.4
• 3.1.5
• 3.1.6

Brand Assets.

Things like your logo, fonts, colors, and icons. Using them the same way everywhere helps your product look and feel like one solid thing.

Accessibility.

Make sure everyone can use your product. Use clear color contrast, logical layout, and support for screen readers and other tools.

• WCAG:
• All Criteria

Writing Guidelines.

Set the rules for how you write. Things like grammar, tone, and word choice should all match. This helps everything feel like it’s coming from one voice.

• WCAG:
• 3.1
• 3.1.1
• 3.1.2
• 3.1.3
• 3.1.4
• 3.1.5
• 3.1.6

Microcopy Guidelines.

Set the rules for how you write. Things like grammar, tone, and word choice should all match. This helps everything feel like it’s coming from one voice.

• WCAG:
• 3.1.2
• 3.1.3
• 3.1.4

Terminology.

Pick the right words once, and use them everywhere. This avoids confusion and keeps things running smoothly.

• WCAG:
• 3.1.3
• 3.1.4
• 3.1.6

Internationalization.

Plan for translation. Set up rules for handling different languages, longer words, and right-to-left text when needed.

• WCAG:
• 3.1
• 3.1.1
• 3.1.2
• 3.1.3
• 3.1.4
• 3.1.5
• 3.1.6

Accessibility.

Make sure your color choices have enough contrast so text is easy to read. Always check your background and text pairings meet at least AA standards.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6

Semantic Colors.

Besides your main brand colors, set up specific colors for things like disabled buttons, background areas, links, and alerts. These should all have a clear role.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6

Dark Mode.

Make a version of your color palette that works in dark mode so your product can match the user’s system settings without breaking.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6

Guidelines.

Write down how to use your colors, when to use them, and what to avoid. This keeps things consistent and easy for the whole team.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6

Order & Sequence.

Your layout of content should be laid out in such a way that it will make logical sense to read as well as be read to in order by assistive technologies.

• WCAG:
• 1.3.1
• 1.3.2

Units.

Start small. Use a clear set of spacing values like 4, 8, 12, and 16. These give you a solid base to build your grid and layout.

Grid.

Use a grid to keep things aligned and balanced. Set up versions for mobile, tablet, and desktop with clear rules for columns, gutters, and margins.

Breakpoints.

Decide ahead of time which screen sizes your design should respond to. This helps your layout work on different devices without surprises.

• WCAG:
• 1.3.4

Spacing.

Keep spacing between elements consistent, both up-and-down and side-to-side. Use simple spacing rules that aren’t tied to the grid so you have flexibility.

Responsiveness.

Font sizes should adjust to the screen size. Bigger text works on desktop, but on smaller screens, scale it down so everything still feels balanced.

• WCAG:
• 1.4.4
• 1.4.5
• 1.4.8
• 1.4.9
• 1.4.10
• 1.4.12

Grid Relation.

Line height and font size should work with your layout grid. This helps text line up nicely with icons, buttons, and other UI pieces.

• WCAG:
• 1.4.4
• 1.4.10
• 1.4.12

Readability.

Make sure your text isn’t too tight or too loose. Watch the spacing between letters, the height between lines, and the length of each line. All of this helps people read more comfortably.

• WCAG:
• 1.4.8
• 1.4.12

Performance.

Custom fonts can slow things down, especially on the web. Use fast-loading fonts and have backups ready. System fonts are a solid choice if speed is a top priority.

Guidelines.

Document font use cases. You may have a singular font for everything, or individually selected fonts for particular use cases such as headings, body text, code snippets, legal copy, and more. Whatever their use case, make sure they are documented with clear rationale to keep your system consistent.

Accessibility.

If an icon does something or means something, give it an accessible name so screen readers can describe it. If it’s just for decoration, no name needed. If you’re shipping code, make sure things like aria-label are included.

• WCAG:
• 1.1.1
• 1.3.1
• 1.3.6

Style.

Pick a style—like outline or filled—and stick with it. This keeps everything looking clean and unified.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6

Naming.

Name your icons based on what they do, not what they look like. For example, call it “play” instead of “triangle.” You can always tag extra keywords to help with search.

• WCAG:
• 3.1.2
• 3.1.3
• 3.1.4
• 3.1.5

Grid Alignment.

Design icons in a size and shape that fits your layout grid. This makes it easier to line things up with text or buttons.

• WCAG:
• 1.3.1
• 1.3.2

Keywords.

Add extra keywords to your icon library to make finding the right one faster and easier.

• WCAG:
• 3.1.2
• 3.1.3
• 3.1.4
• 3.1.5

Reserved Icons.

Keep some icons locked in for specific uses, like navigation or delete. Don’t let them get reused for random stuff. This keeps things clear for users.

Guidelines.

Set rules for how and when to use icons, and what to avoid. Consistency goes a long way.

Shadow.

Set up a few shadow styles that match your elevation levels. Most products only need about 3 or 4. These help show depth and separate layers.

• WCAG:
• 1.3.1
• 1.3.3

Background Color.

In dark mode, shadows don’t always work well. Use slightly different background colors to show depth instead. Link each one to a shadow level so it all stays consistent.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6
• 1.4.11

Z-Index.

Create a clear system for z-index values so you know what should sit on top of what. This helps avoid weird stacking issues.

Accessibility.

Always check for reduced motion settings. If someone prefers less motion, make sure your animations either tone it down or turn off.

• WCAG:
• 2.2.1
• 2.2.3
• 2.3
• 2.3.1
• 2.3.2
• 2.3.3

Easing.

Set a few standard easing types like standard, fast-in, and slow-out. These help your animations feel natural and consistent across the whole system.

• WCAG:
• 2.2.1
• 2.2.3
• 2.3
• 2.3.1
• 2.3.2
• 2.3.3

Duration.

Pick a few go-to timing values for how long animations should run. This keeps things feeling smooth and avoids weird jumps or delays between components.

• WCAG:
• 2.2.1
• 2.2.3
• 2.3
• 2.3.1
• 2.3.2
• 2.3.3

Open vs Closed.

There are two main states (exc. interactive and accessibility states such as hove, focus, active...): open and closed. If there’s an icon (like an arrow), it should clearly show which state it’s in.

• WCAG:
• 1.3.1
• 1.3.2
• 1.4.13

Composition.

The content area should be flexible. It should work with text, images, or even other components inside.

• WCAG:
• 1.3.1
• 1.3.2

Toggle Transition.

Use a smooth, simple animation when opening or closing. This helps users see what’s happening.

• WCAG:
• 2.2.1
• 2.2.3
• 2.3
• 2.3.1
• 2.3.2
• 2.3.3

Content & Trigger Relation.

Make sure assistive tech can link the content to the trigger. If someone focuses the content, they should also hear what it’s related to.

• WCAG:
• 1.3.5
• 1.3.6
• 2.1.1
• 2.1.2
• 2.1.3
• 2.4.3
• 2.4.11
• 2.4.12
• 2.4.13
• 2.5.5
• 2.5.3
• 2.5.8
• 4.1.1

Color.

Use different background colors to show the type of alert, like success, warning, or error. Make sure the text inside has enough contrast to stay readable.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6
• 1.4.11

Title Support.

Including a title helps users quickly get the point, especially if the alert has a longer message.

• WCAG:
• 2.4.6
• 3.1.2
• 3.1.4
• 3.1.5
• 3.1.6
• 4.1.3

Icon Support.

Icons help explain what the alert is about and are useful for people who can’t rely on color alone.

• WCAG:
• 1.1.1
• 1.3.5
• 1.4.5

Actions.

If there’s something the user needs to do, include a clear action button or link that fits the message.

• WCAG:
• 1.3.6
• 2.4.3
• 2.4.4
• 3.1.2

Responsiveness.

Make sure alerts adjust to screen size. On smaller screens, they should go full-width so everything stays readable.

• WCAG:
• 1.4.4
• 1.4.10

Accessibility Role.

Use the correct accessibility role so screen readers know to announce the alert properly.

• WCAG:
• 1.3.6
• 2.1.1
• 2.1.2
• 2.1.3
• 2.1.4
• 2.4.3
• 2.4.11
• 2.4.12
• 2.4.13
• 2.5.3
• 4.1.1

Image.

Avatars should crop images into the right shape and handle whatever image size gets thrown at them, even if the source is unpredictable.

• WCAG:
• 1.1.1
• 1.4.11

Image Fallback.

If the image doesn’t load or isn’t provided, show something else instead. This could be an icon or the user’s initials.

• WCAG:
• 1.1.1
• 1.4.11

Size.

Avatars show up in lots of places, so you’ll need a few different sizes. At the very least, include a small, medium, and large option.

• WCAG:
• 2.5.5
• 2.5.8

Color.

When there’s no image, use a background color that fits the design. Make sure any icon or text over it meets contrast guidelines for readability.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6
• 1.4.11

Avatar Groups.

Stack a few avatars together to show a group of users, like on a shared project or team.

Accessibility Label.

If there’s no visible name, make sure screen readers can describe what or who the avatar represents.

• WCAG:
• 1.3.6
• 2.1.1
• 2.1.2
• 2.1.3
• 2.4.3
• 2.4.7
• 2.4.12
• 2.4.11
• 2.4.12
• 2.4.13
• 2.5.3
• 4.1.1

Color.

Use different colors to show different meanings, like success, warning, or error. Make sure the text or icon on top has enough contrast to stay readable. Make sure all colors have been checked for WCAG contrast thresholds, and are not the sole meaning of the status for those that may be colorblind.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6
• 1.4.11

Variants.

Badges might need different styles depending on where they show up. Some can be bold and bright, others more subtle with soft backgrounds.

• WCAG:
• 1.4.1

Size.

Use a few size options so badges work in different spots—small for UI labels, bigger ones for places like marketing pages.

• WCAG:
• 2.5.5
• 2.5.8

Icon Support.

Add icons next to the text to help show meaning fast. Just make sure they’re clear, even at small sizes.

• WCAG:
• 1.1.1
• 1.3.5
• 1.4.5

Dismissable.

If the badge is showing something like a selected filter, make it possible to remove it with a close or clear button.

• WCAG:
• 2.4.4
• 2.5.3
• 2.1.1
• 2.1.1
• 2.4.3
• 2.4.7
• 2.4.11
• 2.4.12
• 2.4.13
• 2.5.5
• 2.5.8
• 3.2.1

Empty State.

Some badges don’t need text, like a small dot for status. Adjust the style so they still look right without breaking layout.

Positioning.

For things like notification indicators, badges should be easy to place in the corner of an icon or avatar.

• WCAG:
• 1.1.1
• 1.3.6
• 1.4.9

Color.

Use different colors for different button roles—like primary, secondary, success, or danger. Always make sure the text and icon colors meet WCAG AA contrast standards for readability.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6
• 1.4.11

Variants.

Not all buttons should look the same. Primary buttons should stand out, while secondary or subtle buttons can blend in more. The style should match the action’s importance and where it appears.

• WCAG:
• 1.4.1

Size.

Have a few sizes ready. Use smaller ones in tight spaces, and larger ones for forms or touch-heavy areas.

• WCAG:
• 2.5.5
• 2.5.8

Icon Support.

Buttons can include icons alongside text or stand alone as icon-only. If you’re using icon-only buttons, make sure there’s an accessibility label so screen readers can describe what the button does.

• WCAG:
• 1.1.1
• 1.3.5
• 1.4.5

Hover State.

When someone hovers with a mouse, show a clear visual change so they know the button can be clicked.

• WCAG:
• 1.4.1
• 1.4.3

Focus State.

When someone uses a keyboard or assistive tech, the button should show a visible focus ring or style so they can tell where they are.

• WCAG:
• 1.4.3
• 2.1.1
• 2.4.3
• 2.4.7
• 2.4.11
• 2.4.12
• 2.4.13
• 3.2.1

Active State.

Show feedback when the button is being clicked or toggled. This helps people know the press was registered.

• WCAG:
• 1.4.1
• 1.4.3

Loading State.

If the button triggers something that takes time, show a loading indicator. Make sure the button doesn’t change size when loading so layout stays stable.

• WCAG:
• 2.5.2

Disabled State.

Make it clear when a button can’t be used. It should look inactive and not respond to clicks or taps.

• WCAG:
• 2.5.2

Accessibility Role.

The button should always be announced correctly by screen readers, whether it’s a button or a link. Use the right role based on what it does.

• WCAG:
• 2.4.6
• 2.4.4
• 2.5.3
• 4.2.1

Icon Support.

You can use icons next to breadcrumb items to show what each page is about. Just make sure you use them consistently, not just here and there.

• WCAG:
• 1.1.1
• 1.3.5
• 1.4.5

Disabled State.

Sometimes you don’t want a breadcrumb link to be clickable. Allow individual items to be disabled when needed.

• WCAG:
• 2.5.2

Collapsed State.

If there isn’t enough room to show the full list, collapse the middle items so the first and last few stay visible. This keeps things readable without cutting off important context.

Separator.

The slash is the standard, though you don’t have to stick with the default slash. Use a separator that fits your design—but keep it consistent.

Display Modes.

Calendars might need to show more than one month at a time or stack vertically. Support different layouts so they work across various parts of your product and on different screen sizes.

Selected State.

Users should be able to pick one date or a range. Highlight the selected date or dates clearly, and make sure the full range is easy to see.

Month Selection.

Make it easy to switch between months so users can move through dates without getting lost, especially when booking far in advance.

Day Names.

Show short weekday labels (like Mon, Tue, Wed) above the date numbers. This helps users understand where they are in the week at a glance.

Internationalization.

Make sure the calendar supports different regions and languages. This includes using local date formats and the correct order for weekdays (some calendars start on Sunday, others on Monday).

Keyboard Navigation.

All dates should be keyboard focusable in addition to hover and active states. Let users move around using arrow keys and switch months without needing a mouse. Screen reader users should be able to navigate smoothly too.

• WCAG:
• 1.4.1
• 1.4.3
• 2.1.1
• 2.4.3
• 2.4.7
• 2.4.11
• 2.4.12
• 2.4.13
• 3.2.1

State Announcement.

When a date is selected or focused, assistive tech like screen readers should announce it clearly so the user knows what’s happening.

• WCAG:
• 1.4.1
• 1.4.3
• 2.1.1
• 2.4.3
• 2.4.7
• 2.4.11
• 2.4.12
• 2.4.13
• 3.2.1
• 4.1.1
• 4.1.2

Composition.

The inside of a card should be flexible. It should work with text, images, buttons, or even other components. Take into consideration hierarchy and reading order for those using assistive devices so content in your cards are read out in a logical order.

• WCAG:
• 1.3.1
• 1.3.2

Media.

Cards often include media like images or videos. These usually sit across the top or off to the side, depending on the layout.

Actions.

Cards can have actions, like buttons or links, usually placed at the bottom. In some cases, the whole card can be clickable.

• WCAG:
• 1.3.6
• 2.4.3
• 2.4.4
• 3.1.2

Responsiveness.

On smaller screens like phones, cards should stretch to full width so there’s more room for the content.

• WCAG:
• 1.4.4
• 1.4.10

Groups.

You can stack multiple cards together in a list or grid to show a set of related items.

Navigation.

Make sure users can move through the carousel using mouse controls, not just swipe or drag. Arrows or buttons should be easy to click and clear to understand.

Composition.

Each carousel item should be flexible and able to hold different kinds of content—text, images, even other components.

• WCAG:
• 1.3.1
• 1.3.2

Size.

Item layout should adapt to different content. On smaller screens, show part of the next item to hint that more content is scrollable.

• WCAG:
• 2.5.5
• 2.5.8

Touch.

Make the carousel content scrollable with touch gestures, especially on mobile devices.

Responsiveness.

Adjust the layout of carousel items based on the screen size. Items might stack differently or show fewer at a time on smaller screens.

• WCAG:
• 1.4.4
• 1.4.10

Keyboards.

Users should be able to move through the carousel with the keyboard and screen readers, without needing to click arrows or buttons.

Label.

Every checkbox should have a label. Clicking the label should also toggle the checkbox. If the label isn’t shown on the screen, make sure it’s still announced properly for screen readers.

• WCAG:
• 2.4.6
• 3.3.2

Checked State.

Show clearly when a checkbox is selected. This is the value that gets sent with the form.

Error State.

If there’s a problem with the checkbox input, show an error message and change the color of the field to match. Always include both visual and text feedback.

• WCAG:
• 1.4.1
• 3.3.1
• 3.3.3
• 3.3.4
• 3.3.4

Disabled State.

Use this when the checkbox shouldn’t be interactive. Disabled checkboxes don’t send data when the form is submitted.

• WCAG:
• 2.5.2

Intermediate State.

Use this to show when only some options in a group are selected. It usually shows as a dash or shaded box instead of a full check.

Grouping.

You can group multiple checkboxes together so users can pick more than one related option at once.

• WCAG:
• 1.3.1
• 1.3.2

Accessibility.

Checkboxes should work with a keyboard. If you’re using native elements, this should be built in automatically. Along with including hover, focus, and active states.

• WCAG:
• 1.4.1
• 1.4.3
• 2.1.1
• 2.4.3
• 2.4.7
• 2.4.11
• 2.4.12
• 2.4.13
• 3.2.1

Direction.

Dividers should work in both horizontal and vertical layouts to separate different sections or groups of content.

Accessibility Role.

If the divider is more than just decoration—like it’s marking a meaningful break in content—make sure assistive tech can announce its role correctly.

Composition.

Dropdowns should be flexible enough to hold different kinds of content, including icons, text, or even other components. Take into consideration the reading and focus order for those using assistive devices so that they can interpret the content logically.

• WCAG:
• 1.3.1
• 1.3.2

Hover & Focus State.

Dropdowns can open on hover, but that same behavior should also work for keyboard users when the trigger gets focus.

• WCAG:
• 1.4.1
• 1.4.3
• 2.1.1
• 2.4.3
• 2.4.7
• 2.4.11
• 2.4.12
• 2.4.13
• 3.2.1

Dynamic Positioning.

The dropdown should open in a direction that keeps it visible based on where the trigger is on the screen. It should never get cut off or hidden.

Responsiveness.

Make sure the dropdown adjusts to fit smaller screens. What works on desktop might need to shift or resize on mobile.

• WCAG:
• 1.4.4
• 1.4.10

Focus Trapping.

When the dropdown opens, move focus inside it. When it closes, send focus back to the trigger so keyboard users don’t lose their place.

Keyboard Navigation.

Users should be able to move through dropdown items with the keyboard and close the dropdown by pressing escape or tabbing out. Make sure screen readers can announce the dropdown contents properly.

Color.

Icons should use color tokens from your design system. They should also be able to inherit color from their parent element when needed.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6
• 1.4.11

Size.

Offer a few standard icon sizes that line up with your typography scale. This keeps icons and text visually aligned and balanced.

• WCAG:
• 2.5.5
• 2.5.8

Interactivity.

Most icons are decorative, but if one needs to be clickable, wrap it in a proper interactive element like a button or link. That way it stays accessible and works as expected.

Image Fallback.

If the image doesn’t load or the URL is broken, show a fallback. That could be a background color, an icon, or a default placeholder image.

Alt Text.

If the image has meaning or content, always include alt text so screen readers can describe it. Skip alt text only if the image is purely decorative.

Size.

Images should support flexible width, height, and aspect ratio. This lets them scale properly within their parent container and keeps layouts clean.

• WCAG:
• 2.5.5
• 2.5.8

Screen Density Support.

Support different image sizes for different screen resolutions. Load the right one so images stay sharp without slowing things down.

Icon Support.

Icons can be placed next to link text to give extra context, like an external link or download. Don’t use icons by themselves—there should always be a text label.

• WCAG:
• 1.1.1
• 1.3.5
• 1.4.5

Color.

Links should follow your design system’s color tokens. Since they’re text, they should also be able to inherit color from their parent element when needed. Always check that color contrast meets WCAG AA standards and to make sure it will pass against adjacent inline text as well as backgrounds.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6
• 1.4.11

Disabled State.

If a link shouldn’t be clickable, show it as disabled. It should look inactive and not respond to clicks or taps.

• WCAG:
• 2.5.2

Font Inheritance.

Links used in text should match the typography around them. They should automatically inherit font size, weight, and style.

Multiline Display.

Links inside paragraphs should be able to wrap across lines without breaking the layout or causing weird spacing issues.

Accessibility.

Links should be announced correctly by screen readers. Make sure the right role (link or button) is applied based on how it’s being used. Underlines are encouraged to be used to further drive clarity.

Order.

Use bullets, numbers, or custom markers depending on what the list is showing. Choose the style that makes the most sense for the content.

Composition.

Each list item should be flexible. It should support different types of content, including text, icons, or even other components.

• WCAG:
• 1.3.1
• 1.3.2

Accessibility.

Make sure assistive tech can recognize the list, its role, and how many items it includes. Use semantic HTML or the correct ARIA roles when needed.

Color.

Loading indicators should match the color scheme of the area they’re in. Use color tokens from your system for consistency.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6
• 1.4.11

Size.

Use different sizes depending on where the loader appears. A full-page loader should be bigger than one used inside a button.

• WCAG:
• 2.5.5
• 2.5.8

Duration.

If there’s no way to know how long something will take, keep the loader visible until it finishes or fails. If timing is known, use a progress bar or message to show that instead.

Motion.

Respect the user’s system settings. If reduced motion is turned on, slow down or simplify the animation.

Accessibility Label.

If the loader stands alone (not tied to a visible element), add a label so screen readers can announce what’s being loaded.

• WCAG:
• 1.3.6
• 2.5.3
• Name, Role, Value

Composition.

The modal should be flexible enough to hold all kinds of content—text, forms, media, or other components.

• WCAG:
• 1.3.1
• 1.3.2

Actions.

If the modal includes actions (like Save or Cancel), put them in a clear area—usually at the bottom—so users know what to do next.

• WCAG:
• 1.3.6
• 2.4.3
• 2.4.4
• 3.1.2

Close.

There should always be a clear way to close the modal. This can be a close button or one of the actions like Cancel.

Positioning.

Modals are usually centered on the screen, but they can also slide in from the sides if that fits the use case.

Size.

Support different sizes based on the content. Not every modal needs to take up the whole screen.

• WCAG:
• 2.5.5
• 2.5.8

Focus Trapping.

When a modal opens, move focus to the first focusable element inside. Keep the focus trapped there until the modal is closed. Then send focus back to where the user was before.

Keyboard Navigation.

Users should be able to move through all focusable elements in the modal using Tab and Shift+Tab. Pressing Esc should close the modal.

Title & Subtitle Labeling.

Use proper accessibility roles and make sure screen readers can announce the modal’s title and subtitle. If those aren’t visible, add an accessible label instead.

• WCAG:
• 2.4.6
• 2.4.4
• 2.5.3
• 4.2.1

Selected State.

Clearly show which page is selected. The selected page shouldn’t be clickable since the user is already on it. These should be distinct from the additional hover, focus, and active states to navigate to other pages.

• WCAG:
• 1.4.1
• 1.4.3
• 2.1.1
• 2.4.3
• 2.4.7
• 2.4.11
• 2.4.12
• 2.4.13
• 3.2.1

Display Ranges.

Don’t show every page number in long lists. Instead, show a few pages around the current one so users can still navigate quickly without clutter.

Items per Page.

Give users control over how many items they see per page. This helps with flexibility and performance.

Intermediate or Truncated Pages.

If the total number of pages isn’t known, use a simpler display that just shows next and previous controls instead of a full list of page numbers.

Full Page Label Announcements.

Make sure screen readers can announce each page with context—like “Page 3 of 10”—instead of just “3.”

State Announcements.

When a page is focused or selected, let assistive technologies announce that change clearly to the user.

Label.

Show a clear label that tells users what the progress bar is tracking. This helps them know what to expect.

• WCAG:
• 2.4.6
• 3.3.2

Size.

Support a few size options so the progress bar can fit different layouts—big ones for full-screen tasks, smaller ones for compact areas.

• WCAG:
• 2.5.5
• 2.5.8

Duration.

If you know how long something will take, show progress filling up over time. If not, just keep showing the bar until the task finishes or fails.

Accessibility Label.

If you can’t show a label on screen, make sure to add an accessibility label so screen readers can still describe what the bar is for.

• WCAG:
• 2.5.3
• Name, Role, Value

Label.

Every radio button should have a label. Clicking the label should select the radio. If the label isn’t visible, make sure screen readers can still announce what it’s for.

• WCAG:
• 2.4.6
• 3.3.2

Checked State.

Clearly show which option is selected. This is the value that will be sent when the form is submitted.

• WCAG:
• 1.4.1

Error State.

If there’s an issue with the radio group (like a required choice that’s missing), show a clear error message and change the field’s visual style to match.

• WCAG:
• 1.4.1
• 3.3.1
• 3.3.3
• 3.3.4
• 3.3.4

Grouping.

Radio buttons should always be used in a group. This ensures that users can only pick one and won’t get stuck with an unchangeable choice.

• WCAG:
• 1.3.1
• 1.3.2

Accessibility.

Users should be able to select a radio option using the keyboard. Native HTML elements usually handle this out of the box. Make sure your radio inputs utilize hover, focus, active, and disabled states in addition to the described.

• WCAG:
• 1.4.1
• 1.4.3
• 2.1.1
• 2.4.3
• 2.4.7
• 2.4.11
• 2.4.12
• 2.4.13
• 2.5.2
• 3.2.1

Label.

Every select field should have a text label. Clicking the label should open the dropdown. If there’s no visible label, provide one for screen readers.

• WCAG:
• 2.4.6
• 3.3.2

Error State.

If there’s a problem with the selection (like a required field left empty), show an error message and a visual cue like an icon or color change.

• WCAG:
• 1.4.1
• 3.3.1
• 3.3.3
• 3.3.4
• 3.3.4

Disabled State.

Use this when you don’t want users to interact with the select field. Disabled fields won’t send data when the form is submitted.

• WCAG:
• 2.5.2

Placeholder.

If nothing is selected yet, show a placeholder to guide the user. You can also use it as a way to reset the selection.

Helper Text.

Add extra text under the field to explain what the user should choose or why it matters.

• WCAG:
• 3.3.2

Icon Support.

You can include an icon before the selected text to give more context—like a calendar icon for a date picker or a globe for language selection.

• WCAG:
• 1.1.1
• 1.3.5
• 1.4.5

Prefix & Suffix.

Use a prefix or suffix area to add custom visuals or text like flags, currency symbols, or other content that gives more meaning to the selected value.

Accessibility.

If the label isn’t visible, always provide an accessibility label so screen readers can still describe the purpose of the field. Along with covering all of the necessary hover, focus, and active states.

• WCAG:
• 1.4.1
• 1.4.3

Size.

Skeletons are placeholders that show up while real content is loading. They help reduce the feeling of waiting and keep layouts from jumping around.

• WCAG:
• 2.5.5
• 2.5.8

Shape.

Use skeleton shapes that match the real components—like circles for avatars or rectangles for text and buttons—so the layout stays familiar.

Composition.

You can group simple skeletons to represent more complex layouts. It doesn’t need to match the real UI exactly, just give a good sense of structure.

• WCAG:
• 1.3.1
• 1.3.2

Accessibility.

If the user has reduced motion turned on, slow down or remove the skeleton’s animation to respect accessibility settings.

• WCAG:
• 2.3.1
• 2.3.2
• 2.3.3

Label.

Every switch should have a label. Clicking the label should also toggle the switch. If the label isn’t visible, make sure screen readers can still announce what it does.

• WCAG:
• 2.4.6
• 3.3.2

Checked State.

When the switch is on, show it clearly. This usually means the action or setting is active and has already taken effect. Make sure you are communicating this state with more than just color.

Disabled State.

If the switch shouldn’t be used, show it as disabled. It shouldn’t respond to clicks, taps, or key presses.

• WCAG:
• 2.5.2

Keyboard.

Users should be able to toggle the switch using the keyboard. Native elements usually support this by default.

Accessibility.

If you’re not showing a visible label, still provide an accessible name so screen readers can describe what the switch controls along with visual indication.

Composition.

The content under each tab should support a variety of elements—text, images, forms, or even other components.

• WCAG:
• 1.3.1
• 1.3.2

Variants.

Tabs can look different depending on where they’re used. For example, use pill-style tabs for full-page sections or underlined tabs inside cards.

Selected State.

One tab should always be selected by default, and it should be visually highlighted to show which content is active.

Disabled State.

You can disable specific tabs if they’re not available or ready yet. Disabled tabs shouldn’t respond to clicks or keyboard navigation.

• WCAG:
• 2.5.2

Icon Support.

Add icons next to tab labels if it helps explain the content better. Just make sure they’re clear and consistent.

• WCAG:
• 1.1.1
• 1.3.5
• 1.4.5

Equal Width.

When tabs span the full width of a container, you can stretch them so each one takes up the same amount of space.

Accessibility.

Tabs should support full keyboard navigation. Use arrow keys to move between tabs, and allow Home and End keys to jump to the first and last ones.

Label.

Every text area should have a label. Clicking the label should move focus to the field. If there’s no visible label, add one for screen readers.

• WCAG:
• 2.4.6
• 3.3.2

Error State.

If something goes wrong—like a required field is left empty—show a clear error message and a visual style change so users know what to fix.

• WCAG:
• 1.4.1
• 3.3.1
• 3.3.3
• 3.3.4
• 3.3.4

Disabled State.

Use this when the field shouldn’t be editable. Disabled fields should look inactive and won’t send data when the form is submitted.

• WCAG:
• 2.5.2

Placeholder.

Placeholders can guide users when the field is empty, but they shouldn’t replace the actual label. Use them for examples or hints only.

Helper Text.

Add extra info under the field if users need help understanding what to write or how their input will be used.

• WCAG:
• 3.3.2

Size.

Offer different sizes to fit different layouts. Bigger forms like on marketing pages may need a larger field, while compact UIs may need something smaller.

• WCAG:
• 2.5.5
• 2.5.8

Accessibility.

If you’re not showing a label on screen, include an accessibility label so screen readers can still describe the field’s purpose.

Label.

Every text field should have a label. Clicking the label should move focus to the field. If it’s not shown visually, make sure screen readers still get a proper label.

• WCAG:
• 2.4.6
• 3.3.2

Error State.

If the field has a problem (like being left empty when required), show an error message and change the visual style so it’s easy to spot.

• WCAG:
• 1.4.1
• 3.3.1
• 3.3.3
• 3.3.4
• 3.3.4

Disabled State.

Use this to make the field read-only. It should look inactive and won’t send any value when the form is submitted.

• WCAG:
• 2.5.2

Placeholder.

Use placeholders to give examples or short hints, but don’t rely on them to replace the label.

Helper Text.

Show extra info below the field when users might need guidance, such as format rules or what the field is used for.

• WCAG:
• 3.3.2

Icon Support.

You can place an icon inside the field, usually at the start, to give context, such as a search icon for a search input.

• WCAG:
• 1.1.1
• 1.3.5
• 1.4.5

Prefix & Suffix.

Use prefixes or suffixes for added context, such as a dollar sign for prices or a logo for credit card types.

Size.

Offer multiple size options depending on where the field is used. Larger forms might need bigger fields, while tight layouts call for smaller ones.

• WCAG:
• 2.5.5
• 2.5.8

Accessibility.

If no label is visible, provide an accessibility label so screen readers can describe the field’s purpose.

Composition.

Toasts should be flexible enough to include text, icons, buttons, or other components depending on the message.

• WCAG:
• 1.3.1
• 1.3.2

Color.

Add an icon at the start to help users quickly understand the purpose of the toast—especially helpful for colorblind users.

• WCAG:
• 1.4.1
• 1.4.3
• 1.4.6
• 1.4.11

Icon Support.

Most toasts should disappear after a short delay. Make sure users have enough time to read them. If they don’t close automatically, include a clear button to dismiss.

• WCAG:
• 1.1.1
• 1.3.5
• 1.4.5

Timeout.

Most toasts should disappear after a short delay. Make sure users have enough time to read them. If they don’t close automatically, include a clear button to dismiss.

• WCAG:
• 2.2.1
• 2.2.2
• 2.2.3
• 2.2.4
• 2.2.5
• 2.2.6

Stacking.

When multiple toasts are triggered, stack them neatly so they don’t overlap or take over the screen.

Actions.

If the toast has an action (such as Undo or Retry) make it contextual and clear. Only include actions that are directly related to the message.

• WCAG:
• 1.3.6
• 2.4.3
• 2.4.4
• 3.1.2

Focus.

If the toast includes actions, they should be keyboard-focusable. While focused, the toast shouldn’t auto-dismiss.

• WCAG:
• 1.4.1
• 1.4.3
• 2.1.1
• 2.4.3
• 2.4.7
• 2.4.11
• 2.4.12
• 2.4.13
• 3.2.1

Motion.

If the user has reduced motion enabled, simplify or turn off toast animations to respect their preference.

• WCAG:
• 2.2.1
• 2.2.2
• 2.2.3
• 2.2.3
• 2.3.1
• 2.3.2
• 2.3.3

Position.

Tooltips show quick info when a user hovers over or focuses on an element. They’re great for giving extra context without cluttering the interface.

• WCAG:
• 1.4.1
• 1.4.3

Timeout.

Add a short delay before showing the tooltip. This helps avoid them popping up while the user is just moving their mouse around.

• WCAG:
• 2.2.1
• 2.2.2
• 2.2.3
• 2.2.4
• 2.2.5
• 2.2.6

Keyboard.

Tooltips should appear not just on hover, but also when the trigger element gets keyboard focus—so they work for everyone.

• WCAG:
• 1.4.1
• 1.4.3
• 2.1.1
• 2.4.3
• 2.4.7
• 2.4.11
• 2.4.12
• 2.4.13
• 3.2.1

Design System Principles.

List your core values and decision-making rules. This helps others understand why your system works the way it does and keeps contributions consistent.

Getting Started.

Write a simple guide for setting up and using the system. The goal is to help someone build their first feature without needing to bug your team.

Design Best Practices.

Share smart ways to use the system in your design tool, avoid mistakes, and scale designs with less effort.

Development Best Practices.

Cover technical do’s and don’ts—like which dependencies to use and how to avoid common implementation issues.

Component Anatomy.

Break down your components so users know which parts can be changed and what’s off-limits. Helps avoid weird layout bugs.

Component Properties.

List all the supported properties—both in the design file and in code. Try to keep things consistent across platforms to smooth out handoffs.

Component Composition Examples.

Show how smaller components can be combined to make more complex ones. This is especially useful for systems with slots or flexible layouts.

Sandbox Product Example.

Show how smaller components can be combined to make more complex ones. This is especially useful for systems with slots or flexible layouts.

Browser and or OS Support.

Document what browsers and operating systems you officially support. Sync this with your product team so there are no surprises.

Release Cycle.

Set a clear release schedule—especially for major changes. This helps product teams plan updates, test early, and avoid last-minute rushes.

When to Build.

Let teams know when it makes sense to build something themselves. If the need is too specific or one-off, it’s better handled locally than added to the core system. Save system updates for patterns that apply across multiple products.

Horizontal and Vertical Libraries.

Call out the difference between horizontal libraries (shared across multiple products) and vertical ones (built for a single product or feature). Both are valid, but they serve different purposes.

Library Expectations.

Set some basic standards for local libraries. This could include code quality, documentation, naming, and how they should be maintained over time. Nothing too heavy—just enough to keep things consistent.

Release Cycle Alignment.

Local libraries should stay in sync with the main system. When the system gets a major update, local components should be tested and updated too, so nothing breaks and the product isn’t held back.

Decision Log.

Let teams know when it makes sense to build something themselves. If the need is too specific or one-off, it’s better handled locally than added to the core system. Save system updates for patterns that apply across multiple products.

Roadmap.

Plan out your big-picture goals, not just the day-to-day requests. Save time for bug fixes and community needs, but don’t let them take over the whole roadmap.

Stakeholder Mapping.

Set some basic standards for local libraries. This could include code quality, documentation, naming, and how they should be maintained over time. Nothing too heavy—just enough to keep things consistent.

Analytics.

Track what’s working. Use simple metrics like doc site visits, design tool usage, or feedback forms to understand which parts of your system are being used—and what needs more attention.

Ongoing Support “Shifts”.

If more than one person supports the system, take turns handling questions and requests. That way, no one’s buried in Slack all week and everyone gets time to focus on planned work.

SLA.

Set clear expectations on how quickly you’ll handle bugs, questions, or feature requests. This helps teams plan ahead and decide if they should wait or use a workaround.

Support Channels.

Set up clear channels for support—like Slack or Teams—and split them by platform if needed. That way, folks can ask platform-specific questions without confusion.

Templates.

Make it easy to report bugs or request features. Use templates that prompt people for what you need, like screenshots, design ideas, or steps to reproduce the issue so you don’t have to chase it down later.

Regular Updates.

Don’t just ship and stay silent. Share regular updates to keep the community in the loop and excited about new features. Even short posts or changelogs help people know what’s available and how to use it.

Office Hours.

Some things are better solved face-to-face (or Teams, Zoom, Webex, etc...). Offer bookable time slots for teams to talk through tricky problems, review designs, or ask questions one-on-one.

House Rules for the System.

Lay out how your team works, especially around design and development decisions. Be clear that design system work often takes longer because it affects everything, not just one feature.

Contribution Guidelines.

Give step-by-step instructions for setting up a design or dev environment. Help contributors test things properly before submitting changes so they don’t feel lost or blocked.

Feature Proposal Template.

Use a template to guide new feature proposals. It should include things like design mockups, platform impact, and a heads-up on what might break. The goal is to keep changes thoughtful and scalable.

Engagement.

Shout out contributors in release notes or team updates. Recognize their effort and help them get credit with their managers. A little appreciation goes a long way.