Figma'da Renk Erişilebilirliğini Test Etmek: Eklentiler ve İş Akışları

Accessibility testing in Figma is not a post-design checklist step — it should be continuous, embedded into the workflow at the same time color decisions are made. The tools available inside Figma (and directly alongside it) now make this practical: contrast checking, color blindness simulation, and batch accessibility auditing are all possible without leaving the design environment.

This guide covers the primary plugins, their workflows, what each one does well and where it falls short, and how to structure an accessible color workflow from token definition through developer handoff.

Stark Plugin for Contrast Checking

Stark is the most widely adopted accessibility plugin in the Figma ecosystem. The free tier covers WCAG 2.1 contrast checking; the paid tier adds batch checking, color blindness simulation, interactive element annotations, and a vision simulator for the full canvas.

Installing and activating Stark

Install Stark from the Figma Community (Plugins → Browse Community → search "Stark"). After installation, access it via the Plugins menu in any Figma file.

Contrast checking with Stark

Stark's core function: select two layers (or one text layer over a background), run Stark, and it reports the contrast ratio and WCAG compliance status.

Step-by-step workflow:

1. Select a text layer in your design
2. Open Stark (Plugins → Stark → Check Contrast)
3. Stark detects the text layer's fill color and the background color behind it
4. Results show:
5. The exact contrast ratio (e.g., 6.2:1)
6. WCAG AA pass/fail for normal text (≥ 4.5:1) and large text (≥ 3:1)
7. WCAG AAA pass/fail for normal text (≥ 7:1) and large text (≥ 4.5:1)

If the result fails, Stark provides a suggestion: lighter or darker alternative values for either the text or the background that would pass the target ratio.

What Stark contrast checking handles well

Stark correctly handles text that sits on complex backgrounds — if a text layer overlaps a gradient or an image, Stark samples the actual rendered background at the text position rather than using the layer's direct parent fill. This produces more accurate results than tools that only check direct parent colors.

Stark's limitations on contrast

Stark checks contrast at the layer level, not at the design token level. It does not know that a text layer is bound to a text/primary variable — it sees the resolved hex value. This means:

• If you change a primitive variable value, Stark results on existing frames become stale — they reflect the old values until you re-check
• Stark does not flag token pairs that pass in Light mode but fail in Dark mode unless you check each mode separately

This is why combining Stark with token-level contrast validation (checking the raw primitive values against each other) is important. Use ColorFYI's Contrast Checker to validate token pairs at the definition stage — before they appear in any component.

A11y Color Contrast Plugins

Several plugins focus specifically on accessibility without the full Stark feature set. Notable alternatives:

A11y — Color Contrast Checker

This free plugin (available in Figma Community) provides a simple, fast contrast check interface. Select a frame and run the plugin — it iterates through all text layers and reports contrast ratios in a scrollable list. Each item shows the text content, the foreground color, the background color, the ratio, and pass/fail status.

Best use case: A quick audit of a single frame or component set before handoff. Faster than Stark for bulk reviews, though less feature-rich.

Limitation: It does not detect overlapping layers or gradients as accurately as Stark — it checks the direct parent layer's background color, which can yield incorrect results when text sits on a visually complex background.

WCAG Color Contrast Checker (by Anuoluwapo Odunsi)

Another lightweight free option. Similar function to A11y — iterates text layers in a selected frame and reports pass/fail status. The UI presents results as a simple list with green (pass) and red (fail) indicators.

This plugin is reliable for straightforward layouts with solid-color backgrounds. For production use, verify its findings against Stark or an external tool for any layer over non-solid backgrounds.

Choosing between Stark and free alternatives

For solo designers on small projects, the free Stark tier plus A11y plugins covers most needs. For design system teams maintaining a shared library, Stark Pro's batch checking and simulation are worth the investment.

Color Blindness Simulation in Figma

Figma does not have native color blindness simulation. The options are plugin-based simulation and external tool checks.

Stark's vision simulator

Stark Pro includes a Vision Simulator that overlays a color blindness simulation on the entire Figma canvas in real time. Unlike per-color simulation tools, this shows your full design — all components, all context — as it appears to a person with a specific condition.

The simulation types in Stark Pro: - Protanopia (no red cones — red appears very dark) - Deuteranopia (no green cones — the most common, red/green confusion) - Tritanopia (no blue cones — blue/yellow confusion, rare) - Achromatopsia (complete color blindness, grayscale) - Blurred vision (visual acuity simulation)

The simulator is a layer overlay — you can toggle it on and off while reviewing any frame. This enables real-time comparison as you make adjustments.

Using ColorFYI for per-color simulation

For checking specific colors in your design token system — rather than the rendered canvas — ColorFYI's Color Blindness Simulator shows exactly how a given hex value transforms under each simulation type, including the resulting hex code.

This is particularly valuable at the token definition stage. Before committing to a semantic token pair (e.g., status/error = #EF4444 and status/success = #22C55E), simulate both values:

1. Simulate #EF4444 under deuteranopia — it becomes a brownish-olive tone
2. Simulate #22C55E under deuteranopia — it also becomes a similar brownish tone

Both colors converge to indistinguishable values under the most common form of color blindness. This pair is problematic whenever it is used to convey meaning through color difference alone — a fundamental issue to resolve at the token level before it propagates to dozens of components.

The browser DevTools simulation (free, no plugin required)

Chrome and Firefox DevTools include a color blindness simulator in their accessibility tools. In Chrome:

1. Open DevTools (F12 or Cmd+Option+I)
2. Open the Rendering panel (three-dot menu → More Tools → Rendering)
3. Scroll to "Emulate vision deficiencies"
4. Select any deficiency type

While not inside Figma, this simulation applies to your staging or production environment — useful for QA testing the final rendered interface, not just the design mockup.

Batch Checking Entire Frames

Batch checking is the workflow that separates systematic accessibility auditing from ad-hoc spot checks. Instead of selecting individual layers, you audit an entire component or page at once.

Stark Pro batch check workflow

1. Select the frame or component you want to audit (can be the entire page or a specific section)
2. Open Stark → Check Contrast (with the paid tier active)
3. Stark iterates every text layer within the selection
4. Results appear as a scrollable list: each row shows the text layer name, the contrast ratio, and pass/fail status for AA and AAA
5. Click any failed item to navigate directly to that layer in the canvas

For a component library frame containing all variants of a button, card, input, and badge component, a batch check identifies every contrast failure across all variants in one operation — a task that would take an hour of manual checking.

Organizing for efficient batch checks

Structure your Figma file to make batch checks actionable:

• Component pages: Keep all component variants on a single "Components" page, organized in frames by component type. Run batch checks per-component-frame before publishing library updates.
• Screen pages: Keep full screen mockups on separate pages. Run batch checks per-screen before design review sessions or client presentations.
• Accessibility review frames: Create a dedicated frame containing all text/background color combinations from your token system (a "contrast matrix"). Run batch checks on this frame to audit the token system itself, independent of any component composition.

Building a contrast matrix

A contrast matrix is a systematic grid showing every text/background combination in your design system, with contrast ratios pre-calculated. This is particularly useful for dark mode documentation.

Structure:

Use ColorFYI's Contrast Checker to fill in the ratios for each mode. Failing combinations are fixed at the primitive level before being published. The matrix becomes living documentation — update it when primitive values change.

Annotating Accessibility for Developer Handoff

Accessibility annotations in Figma communicate to developers not just what colors were used, but what accessibility requirements those colors must meet in the implementation.

What to annotate

Contrast ratio annotations: For every text/background pair that has a required minimum contrast ratio (especially any pair that passes AA but not AAA), annotate the component with the ratio and the standard it targets.

Example annotation on a button component:

Button label / Button background: 4.7:1 (WCAG AA ✓)
Disabled button label / Disabled background: 2.1:1 (intentional — disabled state)
Focus ring / Page background: 3.2:1 (WCAG AA for UI components ✓)

Non-color indicator annotations: For any element that uses color to convey meaning, annotate the non-color equivalent that must accompany it.

Error state: Red border (#DC2626) + ⚠ Error icon + "Error: [message]" text below field
Success state: Green border (#16A34A) + ✓ Check icon + success text
Required field: Red asterisk (*) + "Required" label (NOT color-only)

Focus indicator annotations: Document the focus ring color, offset, and minimum size. This is frequently missed in design handoff but is required for WCAG 2.2 compliance:

Focus indicator:
  Color: border/focus (#3B82F6 light / #60A5FA dark)
  Offset: 2px
  Width: 2px
  Minimum area: 2px × perimeter of component
  Ensure 3:1 contrast against adjacent colors

Using Figma's annotation tools

Figma provides built-in annotation tools (Inspect → Annotations or the Markup mode in dev handoff). While these do not have accessibility-specific fields, you can use sticky notes (text frames with a distinct color) as annotation callouts positioned near the component.

For teams doing frequent handoffs, community plugins like Figma Tokens Annotation or A11y Annotation Kit (a community file) provide standardized annotation formats that developers recognize immediately.

The accessibility specification document

For significant component releases or design system v2 launches, produce a separate accessibility specification alongside the Figma design:

1. WCAG success criteria: List which SC apply to each component (e.g., 1.4.3 Contrast for text, 1.4.11 Non-text Contrast for UI components)
2. Contrast ratio table: The contrast matrix values for all color pairs used in the component
3. Color blindness compatibility: Simulation results for key color pairs — note whether the component passes color-only testing
4. Testing instructions: How developers should verify color accessibility in their implementation (browser DevTools simulation, automated axe checks, manual screen reader review)

This document becomes the acceptance criteria for developer QA, removing ambiguity about what "accessible" means for each component.

Building an Accessible Color Workflow

An accessible color workflow is not a series of gates at the end of the design process — it is a set of habits distributed across every stage.

Stage 1: Token definition

Before any component is built: - Define semantic token pairs (background/foreground) for every intended color combination - Validate each pair against WCAG AA using ColorFYI's Contrast Checker - Simulate both colors in each intended pair through ColorFYI's Color Blindness Simulator — flag pairs where both colors converge to similar simulated values - Fix failing pairs at the primitive level before committing to the semantic token values

Stage 2: Component design

As components are built: - Use Stark's inline contrast check on every text layer after binding it to a variable - Run Stark batch check on each component frame when variants are complete - Review components in both Light and Dark modes using Figma's variable mode switcher - Check interactive states (hover, focus, active, disabled) specifically — disabled states often have low contrast by design, which is acceptable; document it explicitly

Stage 3: Screen design

As screens are assembled: - Run Stark batch check across each full-screen frame after major layout changes - Test all status messages (error, success, warning, info) — these rely heavily on color and are high-risk for color blindness failures - Verify that every form validation state includes a non-color indicator (icon, text, or pattern)

Stage 4: Handoff

Before delivering to development: - Produce a contrast annotation for every non-obvious color pair in the design - Document non-color redundancy requirements for all color-coded elements - Include color blindness simulation results for the primary status color pairs - Specify focus indicator colors, width, and contrast requirements

Stage 5: QA

After development implementation: - Use browser DevTools color blindness simulation on the rendered application - Run automated axe or Deque Contrast Analyzer scans on production pages - Verify focus indicators are visible and meet contrast requirements in both Light and Dark mode - Spot-check any component that uses a non-standard background color (e.g., a colorful card or status banner) for text readability

Key Takeaways

• Stark is the most capable accessibility plugin in Figma — free tier handles individual contrast checks; paid tier adds batch checking across entire frames and color blindness simulation of the full canvas.
• Free alternatives (A11y, WCAG Color Contrast Checker) are useful for quick spot checks but less accurate on complex backgrounds — cross-check important findings with Stark or external tools.
• Color blindness simulation at the token level (using ColorFYI's Color Blindness Simulator on raw hex values) should happen before components are built — catching problematic pairs at the primitive stage prevents the problem from propagating everywhere.
• Build a contrast matrix documenting all token-pair contrast ratios in both Light and Dark mode — this becomes living documentation and a pre-publish checklist.
• Batch checking (Stark Pro or A11y free plugin) audits entire component frames at once — run batch checks before every library publish, not just at project completion.
• Annotate accessibility explicitly in developer handoff: contrast ratios, non-color redundancy requirements, focus indicator specs, and WCAG success criteria for each component.
• An accessible workflow is distributed across stages — token definition, component design, screen assembly, handoff, and QA — not a single pass at the end.