Build an Accessible Figma Design System

Create an accessible Figma design system with tokens, components, and Claude.

Introduction

30 Second Summary

Visual inspiration feels clear until you need to turn it into a real interface. Without shared rules, each new screen introduces another small inconsistency.

In this project, you will turn your own visual references and user needs into an accessible design system in Figma Design. Claude will help scaffold native Figma content through the Figma remote MCP server while you make the UX and UI decisions.

What You'll Build

A view-only link presents your finished design system as a working showcase where tokens, components, interaction states, and accessibility evidence support one coherent interface.

By the end of this project, you'll have:

A user-centered foundation board that connects audience needs and product tasks to color, typography, spacing, hierarchy, and tone.
A working set of design tokens where semantic names keep interface roles consistent as visual values change.
An accessible component showcase with clear Button feedback, Badge meaning, visible focus, flexible layouts, and documented usage rules.
Secret Mission: build a dark theme that preserves hierarchy, state identity, contrast, and non-color cues through the same semantic structure.

Are there any prerequisites?

You need a computer with internet access plus either existing visual references or a willingness to create a starter mood board. Step 1 covers both free account setups in the browser.

Before We Start

Your design system needs a clear audience, product context, and primary task before it needs colors or components. This checkpoint helps you commit to the people you are designing for and the experience your interface should create.

Connect Claude to a Figma Draft

Claude can only inspect or change a real Figma Design file after you authorize access. That working connection is the foundation for every AI-assisted design task in this project.

You will create a free Figma draft. You will connect Claude through the Figma remote MCP server.

A small connection-check frame will prove that Claude can write to the selected file.

In this step, get ready to:

Create the free browser workspace for this project.
Authorize the Figma connector for your draft.
Prove the connection with a named frame on the canvas.

Create the free workspace

Figma Starter gives you a free place to keep the design system. The draft stays in your personal Drafts area so the project does not depend on paid team-library features.

Open figma.new in a new browser tab.
Complete the free account form if Figma asks you to create an account.
Sign in instead if you already have a Figma account.
Select Starter if Figma asks you to choose a plan.
Click the current file name in the top toolbar.
Enter Accessible Design System as the file name.
Press Enter to save the new name.

You'll see Accessible Design System at the top of the open design file. The file remains in Drafts.

Why Keep the File in Drafts?

The Starter plan supports unlimited drafts. A draft also keeps this project independent from paid team-library features.

Open the Claude website in another browser tab.
Complete the free account form if Claude asks you to create an account.
Sign in instead if you already have a Claude account.
Select Free if Claude asks you to choose a plan.

Your browser workspace is ready for the connection step.

Connect Claude through the Figma connector

A connector lets Claude use another service with your permission. The remote server provides browser-based access to native Figma content.

Review Connector Access

Authorization is a real permission step. You remain in control of every requested change.

Keep Accessible Design System as the selected project file.
Approve only write actions that describe the intended change.

Return to Claude.
Click Customize.
Select Connectors.
Choose Figma from the connector list.
Authenticate with the same Figma account that owns the draft.
Approve the connector authorization for that Figma account.
Return to Claude after the authorization flow completes.

You'll see Figma listed as connected in Claude. The remote server can now work with files that you place in the conversation context.

Authorization connects your account. The file URL points Claude to the exact draft you want it to use.

Switch back to the Accessible Design System draft.
Click the browser address bar.
Copy the complete Figma file URL.
Return to Claude.
Start a new conversation using the new-conversation control in the left sidebar.
Paste the Figma file URL into the message field.
Send the message.

The file URL now sits in the active conversation. Claude has explicit context for Accessible Design System.

Prove the connection

The connector gives Claude permission to use Figma. The linked file URL directs the request to your design-system draft.

Writing to the canvas can feel like handing over control. This request is deliberately small so you can inspect its target before approving it.

Before you send the request, what single frame do you expect to appear in the linked file?

Paste In the linked Figma file, create a small frame named Connection check with the text Claude can see this file. into the active Claude conversation.
Send the request.
Read Claude's requested write action.
Confirm that the target is Accessible Design System.
Approve the matching write action.
Switch back to Figma after Claude completes the request.

You'll see a small frame named Connection check on the canvas. Its text reads Claude can see this file.

You have proved the full working loop. Claude can write native content into the selected draft.

Frame Missing from the Canvas?

Confirm that the active Claude conversation contains the URL for Accessible Design System.
Confirm that Figma still appears as an authorized connector in Claude.
Check that the requested write action targets the correct file.

If the frame still does not appear, help me troubleshoot the Claude and Figma connection.

The connection test belongs in a small Setup area. This keeps it available as evidence without mixing it into the design foundations you create next.

Double-click the current page name in the left sidebar.
Rename the page Design System.
Select the frame tool from the top toolbar.
Draw a small frame in an empty part of the canvas.
Rename the new frame Setup in the layer list.
Drag Connection check into the Setup frame.

Before your final check, which file label, page label, frame name, and text should confirm that the setup is complete?

Confirm that Accessible Design System appears as the file name.
Confirm that Design System appears as the page name.
Expand Setup in the layer list.
Select Connection check in the expanded area.

You'll see the selected Connection check frame inside Setup. The canvas shows the text Claude can see this file.

Your browser-based design loop is ready. Next, you will turn user needs and visual references into foundations for your own interface system.

Build Visual Foundations

Claude can now work inside your Figma Design draft. The connection check proved that your Claude workflow can produce visible canvas changes.

A strong interface begins with a clear user and task. Visual choices become useful when they improve comprehension, hierarchy, feedback, or trust.

In this step, you will turn your own context and references into one foundation board. You will then test how its visual language behaves as interface content.

In this step, get ready to:

Define the audience, product context, primary task, and desired experience for your system.
Build one visual foundation board from your own references.
Test and document unsafe and safe text pairings with Figma Color Contrast Checker.

Define the user and source direction

Your source frame combines a short UX brief with visual evidence. This gives every later design decision a reason beyond personal taste.

The two routes below create the same Design Brief / Source frame.

I have visual references

Use this route if you already have a mood board, screenshots, brand references, or interface examples.

Switch to the Design System page in Figma Design.
Drag your visual references onto an empty area of the canvas.
Select the frame tool from Figma's top toolbar.
Draw a frame around the imported references.
Rename the frame Design Brief / Source in the layer list.
Add text that identifies your target audience.
Add text that identifies the product context and primary user task.
Add three words that describe the experience the interface should create.

You should see one source frame containing visual references plus a written audience, context, task, and experience direction.

I need a starter mood board

A starter mood board gives you enough visual material to begin. You will still connect every choice to a user and product need.

Create an editable starter mood board by pasting this prompt into your active Claude conversation:

In the linked Figma file, create a frame named Design Brief / Source.

Add four editable text areas labeled Target audience, Product context, Primary user task, and Desired experience. Add five editable color swatches, one editable serif sample, one editable sans-serif sample, and three editable tone-word labels.

Keep the layout simple. Every field must remain easy to replace with choices for my own interface system.

What does this prompt create?

The UX brief connects the system to a real audience and task.
The swatches establish a starting color direction.
The type samples separate expressive and interface roles.
The tone words create a test for later visual decisions.

Send the prompt to Claude.
Review the requested write action for the linked file.
Allow the action after confirming that it targets Accessible Design System.
Return to Figma Design.
Replace each UX brief prompt with your own audience, context, task, and experience.
Replace the five swatch fills with colors that support the intended experience.
Choose one serif and one sans-serif family from the font picker.
Replace the three tone labels with words that describe the interface.

Your starter mood board should contain a completed UX brief, five colors, two type directions, and three tone words.

Starter mood board missing items?

Confirm that Claude created the frame in Accessible Design System.
Ask Claude to add only the fields missing from Design Brief / Source.

If the frame still differs from the prompt, help me correct my starter mood board.

Build the foundation board

A foundation board turns source material into interface rules. It should show how color, type, spacing, and hierarchy support the primary user task.

Scaffold your foundation board by pasting this prompt into the active Claude conversation:

In the linked Figma file, use Design Brief / Source to create one foundation board named Interface Foundations.

Start with a short summary of the target audience, product context, primary user task, and desired experience. Include the five selected colors with visible labels. Use the selected serif for expressive headings and the selected sans-serif for interface and body text.

Add a type hierarchy with display, heading, body, label, and helper-text roles. Add a small spacing scale and examples of compact, standard, and spacious layout density. Add three tone words and short rationale labels that connect each visual choice to readability, hierarchy, feedback, or trust.

Keep decoration restrained. Make the primary task and content hierarchy clear at a glance.

What does this prompt create?

The brief keeps the board grounded in a user and product task.
The type hierarchy assigns a job to each text style.
The spacing examples show how density changes emphasis and scanability.
The rationale labels make design decisions reviewable.

Send the prompt to Claude.
Review the requested write action against Design Brief / Source.
Allow the action after confirming its target and purpose.
Return to Figma Design.

You should see one board named Interface Foundations beside its source frame.

Confirm that the board names the intended audience and primary task.
Confirm that display, heading, body, label, and helper text have visibly different roles.
Confirm that the primary task has the strongest visual emphasis.
Compare every color and font choice with Design Brief / Source.
Remove any decoration that competes with content hierarchy.
Adjust the spacing examples until compact, standard, and spacious density are easy to distinguish.
Confirm that each rationale explains a UX or UI effect.

The board should now communicate who the interface serves, what users need to do, and how the visual system supports that task.

Foundation board feels unclear?

Check that Claude used the existing source frame in the linked file.
Correct one unsupported choice at a time to preserve useful parts of the draft.

If the hierarchy still feels unclear, help me review my foundation board.

Test interface readability

A palette records available colors. Contrast testing decides which roles those colors can perform safely.

Duplicate one normal body-text sample inside Interface Foundations.
Set the duplicate's background to one of your light surface colors.
Set the duplicate's text to that same color.
Record the text value as your tested foreground hex.
Record the background value as your tested background hex.

The text should disappear into its background. Before you test it, what contrast result do you expect?

Open the Figma Color Contrast Checker in a new browser tab.
Enter your tested foreground hex under Foreground.
Enter your tested background hex under Background.

The ratio should read 1:1. The Normal text result should read Fail.

What did the failure prove?

Color availability does not establish safe usage. Semantic roles will prevent this surface color from being assigned to normal text on the same surface.

Change the duplicate's text to the darkest color in your palette.
Test the new text and background values in the checker.
Darken the text color if the Normal text result still fails.
Record the passing text value as your passing foreground hex.
Record the passing background value as your passing background hex.

Your corrected normal-text pair should reach at least 4.5:1 and show an AA pass.

Document both results by pasting this prompt into the active Claude conversation:

In Interface Foundations, keep the failed normal-text sample using foreground [[LOW_CONTRAST_FOREGROUND="your tested foreground hex"]] and background [[LOW_CONTRAST_BACKGROUND="your tested background hex"]]. Label it Fails as normal text.

Add a passing sample using foreground [[SAFE_FOREGROUND="your passing foreground hex"]] and background [[SAFE_BACKGROUND="your passing background hex"]]. Label it Passes AA for normal text.

Add a compact contrast card that records both tested pairs and this lesson: Palette colors are ingredients. Semantic roles determine safe usage.

What does this prompt document?

The failed sample preserves evidence of the unsafe role assignment.
The passing sample identifies a viable text and surface relationship.
The contrast card turns accessibility testing into system documentation.

Send the documentation prompt to Claude.
Review the requested write action against Interface Foundations.
Allow the action after confirming both samples remain visible.
Return to Figma Design.

You should see one failed pair, one passing pair, and a contrast card beside your visual foundations.

Contrast documentation incomplete?

Confirm that the failed pair uses the same foreground and background value.
Confirm that the passing pair matches the values that produced the AA result.

If either card is incomplete, help me correct my contrast documentation.

Your visual direction now has a user, a task, and measurable accessibility evidence. Next, you will turn those decisions into reusable tokens that keep the interface consistent.

Create Reusable Tokens

Your Interface Foundations board now connects visual direction to a user, a task, and measurable readability. The documented contrast failure also proves that palette names cannot explain safe interface usage.

This step turns those decisions into reusable design tokens. Primitive tokens store raw values, while semantic tokens describe the job each value performs.

A well-structured token system improves consistency and makes change predictable. One deliberate edit can update every connected use without losing the interface's hierarchy.

In this step, get ready to:

Create one primitive collection for your colors and measurements.
Connect interface roles to primitive values with semantic aliases.
Prove that the token structure produces consistent, accessible UI changes.

Create the primitive collection

A primitive token stores one raw design value. Its name describes what the value is without promising where the interface will use it.

Claude can read the labeled colors in your foundation board and scaffold the collection. You will inspect every generated value before relying on it.

Create the primitive collection by pasting this prompt into your active Claude conversation:

In the linked Figma file, use Interface Foundations to create a variable collection named System Primitives.

Create one Color variable for each of the five labeled palette colors. Name each variable with the pattern color/visual-name, using a short visual description from the board.

Create these Number variables: space/1 = 4, space/2 = 8, space/3 = 16, space/4 = 24, space/5 = 32, and radius/control = 8.

Do not assign interface jobs such as text, action, success, or warning to primitive names. Keep every generated value visible for review.

What does this prompt create?

The color variables preserve your raw palette without assigning UI meaning.
The spacing scale creates a repeatable rhythm for layout and component padding.
The control radius gives related interactive elements a consistent shape.

Send the prompt to Claude.
Review the requested variable changes for Accessible Design System.
Allow the action after confirming that it creates System Primitives.
Return to Figma Design.
Click Variables in the left navigation bar.
Open System Primitives from the collections list.

You should see five color variables, five spacing variables, and one control-radius variable.

Compare each generated color value with its labeled swatch in Interface Foundations.
Correct any value that does not match its source swatch.
Confirm that every primitive name describes appearance or measurement.
Remove any primitive name that describes an interface purpose.

Your primitive collection should now expose the raw ingredients of your system without deciding how the interface uses them.

Primitive collection incomplete?

Confirm that Claude created Color variables for palette values and Number variables for measurements.
Check that each variable belongs to System Primitives.

If a row is missing or misplaced, help me review my primitive tokens.

Build semantic aliases

A semantic token names an interface role such as default text or a focus ring. An alias connects that role to a primitive while keeping purpose separate from appearance.

Why separate purpose from value?

Semantic names let components share the same language. A Button and a Badge can both use text/on-action without knowing which raw color currently supplies it.

This separation protects consistency during redesigns. Changing one primitive can update many uses while each semantic role stays understandable.

Create the semantic structure by pasting this prompt into your active Claude conversation:

In the linked Figma file, create a variable collection named System Semantic.

Create these Color variables: background/canvas, background/surface, text/default, text/muted, text/on-action, action/default, action/hover, border/default, focus/ring, status/success, status/warning, and status/error.

Alias background/canvas to the primitive matching [[SAFE_BACKGROUND="your passing background hex"]]. Alias text/default to the primitive matching [[SAFE_FOREGROUND="your passing foreground hex"]].

Choose candidate primitive aliases for the remaining roles from System Primitives. Preserve clear hierarchy between canvas and surface. Keep action/default and action/hover visually distinct. Give focus/ring strong contrast against adjacent surfaces. Keep each status distinguishable without relying on color alone later.

Add a small documentation frame named Token Decisions. List each semantic role, its primitive alias, and one sentence explaining the UX or UI purpose of the role.

What does this prompt create?

The safe text pair becomes the default reading relationship.
Surface roles establish depth without adding arbitrary decoration.
Action roles create predictable feedback across interactive components.
Focus and status roles reserve meaning for accessibility-critical cues.

Send the prompt to Claude.
Review the requested aliases before approving them.
Confirm that background/canvas maps to your passing background primitive.
Confirm that text/default maps to your passing foreground primitive.
Allow the action after confirming the collection name and alias targets.
Return to the Variables view in Figma Design.

You should see System Semantic with twelve purpose-based roles linked to raw values in System Primitives.

Confirm that canvas and surface roles create a visible layer relationship.
Confirm that default and muted text have different emphasis.
Confirm that default and hover actions remain visibly related.
Confirm that the focus role stands out against both canvas and surface colors.
Read every rationale in Token Decisions.
Replace any rationale that describes appearance without explaining interface purpose.

The semantic collection should now describe how your interface communicates hierarchy, action, focus, and status.

Alias unavailable?

Confirm that every semantic role and target primitive use the Color variable type.
Check that each alias points into System Primitives.

If an alias is unavailable, help me diagnose my semantic aliases.

Prove the token system

A token system earns its value when a controlled change updates the interface consistently. A small playground makes that behavior visible before you build reusable components.

Create a token demonstration by pasting this prompt into your active Claude conversation:

In the linked Figma file, create a frame named Token Playground beside Token Decisions.

Build a small interface sample containing a canvas, a surface card, a heading, body text, one primary action, one focus indicator, and three status examples. Bind every color to the matching variable from System Semantic.

Bind spacing and control radius to matching values from System Primitives. Add labels that show the semantic role used by each visible element. Keep the layout focused on hierarchy and state communication.

What does this prompt create?

The canvas and card make surface hierarchy visible.
The heading and body text demonstrate reading emphasis.
The action and focus indicator show interactive priority.
The statuses prepare the same semantic language for reusable components.

Send the prompt to Claude.
Review the requested write action against the two variable collections.
Allow the action after confirming every visible color uses a semantic variable.
Return to Figma Design.

You should see a Token Playground frame with labeled surface, text, action, focus, and status roles.

Before the change, predict which visible elements will update if you edit the primitive behind action/default.

Open System Semantic in the Variables view.
Identify the primitive aliased to action/default.
Open that primitive in System Primitives.
Change the primitive to a visibly different temporary color.
Return to Token Playground.

Every element using action/default should update together. Elements using unrelated semantic roles should remain unchanged.

Restore the primitive to its original color.
Record the primary-action text value as your action text hex.
Record the primary-action background as your action background hex.
Test the action pair in Figma Color Contrast Checker.

The primary-action text should show an AA pass for normal text. If it fails, change the primitive alias and retest before continuing.

Record the focus-ring value as your focus ring hex.
Record its adjacent surface as your adjacent surface hex.
Test the focus ring against the adjacent surface.
Update the focus primitive if the result is below 3:1.

Your playground should now retain its hierarchy while the action text passes AA and the focus indicator reaches at least 3:1 against its adjacent surface.

Token changes not propagating?

Confirm that the playground layers use semantic variables instead of raw color values.
Check that you restored the temporary primitive edit before testing contrast.

If connected elements did not update together, help me inspect my token bindings.

Your system now turns user-centered visual decisions into predictable interface roles. Next, you will use those roles to build components with clear behavior, feedback, and accessibility.

Build Accessible Components

Your semantic tokens now describe hierarchy, action, focus, and status in Figma Design. The next test is whether reusable components can preserve those decisions through real interface states.

A component is more than a repeated shape. It sets expectations for affordance, feedback, content, sizing, and accessibility wherever an interface uses it.

You will build Button and Badge component sets, then audit them in a small interface showcase. Claude will scaffold native structures while you judge whether each state communicates clearly.

In this step, get ready to:

Build a Button component set with clear interaction feedback.
Build Badge variants that preserve status meaning without color.
Audit and share a responsive component showcase with usage guidance.

Build the Button component set

Buttons need to look actionable before interaction and provide feedback after it. Their states should feel related while remaining easy to distinguish.

What should each state communicate?

The default state establishes the action's normal appearance. Hover and active states confirm that the control responds to input.

Focus supports keyboard orientation. Loading communicates progress, while disabled explains that an action is temporarily unavailable.

Claude's write request changes native layers in your file. Confirm the target file and requested component structure before approving it.

Scaffold the Button set by pasting this prompt into your active Claude conversation:

In the linked Figma file, use System Semantic and System Primitives to create a native component set named Button.

Create one State property with these values: default, hover, active, focus, loading, and disabled. Use auto layout in every variant. Use Save changes as the sample label. Size each variant to at least 44 by 44 pixels as a generous interaction target.

Bind colors to semantic variables. Make hover and active visibly different from default. Use focus/ring for a clear focus indicator. Keep the loading state the same width as default and include a visible progress cue with text. Keep disabled text readable while reducing its visual priority.

Add a short guidance card. State that Button is for clear interface actions. Recommend verb-led labels. Warn against vague labels such as Click here and against using multiple primary actions in one small region.

What does this prompt create?

Auto layout lets the control adapt when its label changes.
The shared State property makes feedback predictable across instances.
Semantic bindings keep visual behavior connected to the token system.
Usage guidance protects the component from inconsistent content choices.

Send the prompt to Claude.
Review the requested write action for Accessible Design System.
Confirm that the request creates one native Button component set.
Allow the action after confirming all six states.
Return to Figma Design.
Inspect every generated Button variant before using an instance.

You should see one Button component set containing six labeled variants.

Why inspect Claude's draft?

Write-to-canvas output can require manual cleanup during the current beta. Inspect hierarchy, spacing, and semantic bindings before those decisions spread through instances.

Confirm that every variant uses auto layout.
Confirm that every variant measures at least 44 by 44 pixels.
Confirm that hover and active states provide visible feedback.
Confirm that the focus variant shows a clear perimeter around the Button.
Confirm that loading retains a readable label and visible progress cue.
Confirm that disabled remains legible without looking actionable.
Confirm that the guidance recommends concise verb-led labels.

The Button set should now communicate availability, interaction, progress, and keyboard focus without changing its underlying structure.

Open Assets.
Insert a fresh Button instance onto the canvas.
Change its State property through all six values.
Replace Save changes with Create accessible report.

You should see the instance switch states while remaining connected to the component set. The longer label should expand the Button without breaking its padding.

Button behavior inconsistent?

Confirm that the six variants share one State property.
Check that auto layout applies to the content container in every variant.

If the state or label does not update correctly, help me diagnose my Button component set.

Build the Badge component set

Badges summarize compact status information. Their meaning should survive grayscale, low vision, and quick scanning.

Color can reinforce a status, but it cannot carry the message alone. Each variant needs a distinct native-shape icon and a concise text label.

Scaffold the Badge set by pasting this prompt into your active Claude conversation:

In the linked Figma file, use System Semantic and System Primitives to create a native component set named Badge.

Create one Status property with these values: neutral, success, warning, and error. Use auto layout in every variant. Include a distinct native-shape icon and a visible text label in every status.

Bind fills, text, borders, and icons to appropriate semantic variables. Keep the four variants equal in structure and spacing. Make each status understandable from its icon and label without color.

Add a short guidance card. State that Badge is for compact status information. Recommend short labels that describe the current state. Warn against using Badge for actions or using color as the only explanation.

What does this prompt create?

The shared structure makes every status scan in the same way.
Icons and text preserve meaning when color is unavailable.
Usage guidance separates status communication from interactive controls.

Send the prompt to Claude.
Review the requested write action for the Badge set.
Confirm that every variant includes an icon and text label.
Allow the action after confirming the four status values.
Return to Figma Design.

You should see one Badge component set with neutral, success, warning, and error variants.

Confirm that every variant uses the same spacing and layout structure.
Confirm that each status uses a distinct native-shape icon.
Confirm that each label names the current status.
View the variants in grayscale or temporarily remove their fills.
Identify every status using only its icon and label.
Restore the semantic status fills.

Every status should remain identifiable without color. Restoring the fills should add emphasis without changing the meaning.

Open Assets.
Insert a fresh Badge instance onto the canvas.
Change its Status property through all four values.
Replace one label with Awaiting review.

You should see the instance switch statuses while remaining attached to the component set. The longer label should expand the Badge without breaking its icon alignment.

Badge meaning or layout broken?

Confirm that the four variants share one Status property.
Check that no icon disappears when the label changes.

If a status loses meaning or alignment, help me repair my Badge variants.

Audit and share the system

A component audit turns design intent into evidence. It checks whether reusable states preserve hierarchy, feedback, readability, focus, target size, responsive sizing, and non-color meaning.

Create the showcase and audit area by pasting this prompt into your active Claude conversation:

In the linked Figma file, create a frame named Accessible Design System Showcase.

Use instances from the Button and Badge component sets. Show all Button states, all Badge statuses, one Button with a long label, and one Badge with a long label. Keep every instance attached to its main component.

Add an audit area with sections named Hierarchy and content, Interaction feedback, Responsive layout, and Accessibility. Include the Button and Badge usage guidance beside their examples.

Use semantic variables for every visible color. Use primitive spacing and radius variables for layout. Keep the showcase focused on how the system behaves, not decorative presentation.

What does this prompt create?

The state overview makes interaction feedback easy to compare.
Long labels reveal whether auto layout supports realistic content.
The audit categories connect component quality to UX and UI principles.
Attached instances prove that the showcase still belongs to the reusable system.

Send the prompt to Claude.
Review the requested write action for the showcase.
Confirm that the request uses component instances instead of detached copies.
Allow the action after confirming the four audit categories.
Return to Figma Design.

You should see a showcase containing every state and status, realistic label lengths, usage guidance, and a structured audit area.

Confirm that the default Button is the clearest available action.
Confirm that hover, active, focus, loading, and disabled each communicate a different state.
Confirm that long labels preserve padding and alignment.
Confirm that each Badge remains identifiable without its fill color.
Confirm that no usage example relies on vague action text.
Confirm that all showcase colors use semantic variables.

The showcase should now demonstrate understandable hierarchy, predictable feedback, flexible content, and consistent token usage.

Enter your action text hex under Foreground in Figma Color Contrast Checker.
Enter your action background hex under Background.
Record the observed normal-text result in the accessibility audit.
Enter your focus ring hex under Foreground.
Enter your adjacent surface hex under Background.
Record the observed interface result in the accessibility audit.

The action text should pass AA for normal text. The focus indicator should reach at least 3:1 against its adjacent surface.

Confirm that every Button state meets the project's 44 by 44 pixel interaction target.
Confirm that the focus indicator forms a visible perimeter around the Button.
Confirm that every Badge includes an icon and text label.
Confirm that the loading state includes visible progress feedback.
Add the outcome of each check to the accessibility audit.

That is the system working as a system. Its tokens, states, content rules, layout behavior, and accessibility evidence now reinforce one another.

Before the final share check, predict whether a viewer can understand the primary action and every status without opening the layer panel.

Click Share in Figma Design.
Set link access to view-only.
Click Copy link.
Open the copied link in a private browser window.
Inspect the showcase without edit controls.

You should see every Button state, every Badge status, realistic content examples, usage guidance, and the completed audit in view-only mode.

View-only showcase unavailable?

Confirm that the link targets Accessible Design System.
Check that link access permits viewing without edit access.

If the showcase is missing or access is blocked, help me troubleshoot my shared showcase.

Secret mission

Add a Free-Plan Dark Theme

Build a free-plan dark token set with matching semantic roles. Rebind a duplicated showcase to those roles. Prove that its contrast and non-color cues still hold.

Clean Up Your Resources

This project has no ongoing costs because every resource uses free access. Decide whether to keep the Figma Design draft, pause the Claude connection, or delete both resources.

Resources you used:

Figma Design draft named Accessible Design System in Drafts.
Authorized Figma connector in Claude through the Figma remote MCP server.

Keep everything running

No action is needed. Choose this if you want to keep refining the system or sharing its view-only link.

Keep Accessible Design System in Figma Drafts for future iteration.
Leave the Figma connector authorized in Claude.
Retain the tested view-only link for sharing the light and dark showcases.

Pause - I'll come back to this later

Disable the connection to stop Claude from accessing Figma while preserving the complete design-system draft.

Switch back to Claude.
Click Customize.
Select Connectors.
Locate the Figma connector.
Disable the Figma connection using its status control.

Your foundations, variables, components, audit documentation, and showcase frames remain intact in Figma Drafts.

Delete - I don't want to use this again

This gives the project a clean reset. Your Figma and Claude accounts stay intact.

Return to the Figma file browser.
Select Drafts in the left navigation.
Locate Accessible Design System.
Open the draft's file menu.
Use the file menu's delete control to remove the draft.

The connector is managed separately from the draft. Removing its authorization closes Claude's access to the Figma account.

Switch back to Claude.
Click Customize.
Select Connectors.
Locate the Figma connector.
Use the connector's removal control to remove its authorization.

Nice Work!

Great work! Your Figma Design draft is now a shareable accessible design system.

You've learned how to:

Turn a user and product brief into visual foundations with purposeful color, type, spacing, hierarchy, and documented design reasoning.
Build primitive and semantic tokens that keep interface roles understandable while connected values change across the system.
Create accessible Button and Badge component sets with predictable feedback, responsive labels, visible focus, non-color meaning, and tested contrast.
Complete the optional Secret Mission by building a Semantic Dark collection that preserves hierarchy, component identity, focus, contrast, and status meaning.

Ready to quiz yourself?