| name | colors |
| description | Check color usage in your app (web or React Native) for accessibility compliance, including contrast, color-vision deficiencies, and sensory sensitivity. |
| allowed-tools | Bash Read mcp__plugin_accessibility_contrast-calculator__calculate_contrast mcp__plugin_accessibility_contrast-calculator__batch_calculate_contrast |
| disable-model-invocation | true |
Output format
Structure your ENTIRE response using exactly the template below. Do NOT write any prose, explanation, or analysis outside of this structure. Fill each section in order. Do NOT reorder or rename sections. If a section has no violations, include it with its skip note — never omit a section entirely.
Color Accessibility Report
Summary
| Check | Status |
|---|
| Contrast (light theme) | ✅ Pass / ❌ Fail / ⚠️ Ambiguous |
| Contrast (dark theme) | ✅ Pass / ❌ Fail / ⚠️ Ambiguous |
| Color-only indicators | ✅ Pass / ❌ Fail |
| Sensory sensitivity | ✅ Pass / ❌ Fail |
1. Contrast issues
Skip this section if all contrast checks passed.
Thresholds reminder:
| Text type | Web | React Native | Required ratio |
|---|
| Normal text | < 24px (or < 18.67px bold) | < 18pt (or < 14pt bold) | ≥ 4.5:1 |
| Large text | ≥ 24px (or ≥ 18.67px bold) | ≥ 18pt (or ≥ 14pt bold) | ≥ 3:1 |
| Disabled text | any | any | ≥ 3:1 |
| Focus indicator | web only | — | ≥ 3:1 |
| Element | Location | Text size | Foreground | Background | Ratio | Result |
|---|
<ComponentName> | path/to/file.tsx:42 | BOTH | #333333 | #FFFFFF | 12.6:1 | ✅ |
<ComponentName> | path/to/file.tsx:88 | SMALL | #AAAAAA | #FFFFFF | 2.3:1 | ❌ |
Ambiguous colors (cannot be analyzed):
path/to/file.tsx:55 — var(--color-primary) on var(--surface-bg): unresolved CSS custom properties
2. Color-only indicators
Skip this section if no violations were found.
| Element | Location | Issue |
|---|
| Error message | path/to/file.tsx:102 | Error state indicated only by red text — no icon or label |
3. Sensory sensitivity
Skip this section if no violations were found.
| Element | Location | Issue |
|---|
| Banner | path/to/file.tsx:14 | Highly saturated color (#FF0000) used as background |
Would you like to know more about color accessibility or why accessibility matters? I can dive deeper into color guidelines using the colors skill, or explain the broader importance of accessibility with the why-accessibility skill.
Color Accessibility Verification Guidelines
These rules define when color usage in the application is considered accessible.
The guidelines align with WCAG 2.1 and include additional constraints for color-vision deficiencies and sensory sensitivity.
0. Prerequisite rules
These rules define how the LLM must interpret color information before applying accessibility checks.
0.1 Ambiguous color handling
If the LLM cannot determine the actual rendered color value, it must not guess.
A color is considered ambiguous if any of the following is true:
- The color is defined through an unresolved CSS custom property (
var(--color-primary)) or design token whose value cannot be statically resolved
- The color depends on runtime logic that cannot be statically evaluated
- The color is inherited from an unknown parent
- The color is affected by an unknown theme, mode, or configuration
If a color is ambiguous:
- The LLM must not attempt contrast or accessibility analysis
- The LLM must report the color as "not analyzable due to ambiguity"
- The report must include the reason for ambiguity (e.g. unknown theme, unresolved CSS variable)
0.2 Named color resolution
If a color is specified using a standard color name (e.g. black, white, red, blue, green):
- If there is no theme or configuration overriding it, the LLM must treat it as the default CSS color value
- If there is a theme, token, or configuration that can override named colors, the LLM must resolve the final value from the theme
- If resolution is not possible, the color is considered ambiguous
0.3 CSS color format support
The calculate_contrast and batch_calculate_contrast tools accept:
- Hex:
#rgb, #rrggbb, #rgba, #rrggbbaa
- RGB / RGBA:
rgb(255, 0, 0), rgba(255, 0, 0, 0.5)
- HSL / HSLA:
hsl(120, 50%, 50%), hsla(120, 50%, 50%, 0.8)
Semi-transparent colors are automatically alpha-composited before contrast is computed:
- A semi-transparent background is composited over white
- A semi-transparent foreground is composited over the (resolved) background
Relative units (em, rem, %) and opacity CSS properties are not handled by the tool — the LLM must resolve them to absolute color values before calling the tool.
1. Contrast requirements (low vision)
1.1 Definition
A contrast ratio is the ratio of perceived luminance between the foreground (text, icon, or control) and background (surface behind the foreground).
Always use the calculate_contrast MCP tool to compute contrast ratios. Never calculate them manually. For multiple color pairs, use batch_calculate_contrast in a single call. Do not try to find a passing alternative for a failing color.
1.2 Text contrast rules
For every text element, the LLM must verify the contrast ratio. Size thresholds and unit resolution differ by platform:
| Rule | Web | Mobile (React Native) |
|---|
| Normal text threshold | < 24px / < 1.5rem (or < 18.67px / < 1.167rem bold) → ≥ 4.5:1 | < 18pt (or < 14pt bold) → ≥ 4.5:1 |
| Large text threshold | ≥ 24px / ≥ 1.5rem (or ≥ 18.67px / ≥ 1.167rem bold) → ≥ 3:1 | ≥ 18pt (or ≥ 14pt bold) → ≥ 3:1 |
| Relative units | Resolve em/rem against computed base font size (default: 16px) | Use pt units directly; 18pt ≈ 24px at 96 dpi |
Regardless of platform:
- Disabled text must maintain a contrast ratio ≥ 3:1
- CSS
opacity must not reduce the effective contrast below the required threshold — evaluate opacity-adjusted colors, not raw values
1.3 Non-static backgrounds
If a foreground color appears on:
- An image
- A gradient
- A dynamically changing surface
Then:
- The worst-case contrast ratio must meet the applicable threshold
- If worst-case contrast cannot be guaranteed, the usage must be rejected
1.4 Color variants
For all color variants (primary, secondary, tertiary, theme variants):
- Contrast requirements must be evaluated independently
- A variant that fails contrast must not be used for text or essential UI
1.5 Focus indicators (web only)
For web applications, interactive elements (links, buttons, inputs, etc.) must have a visible focus indicator that meets contrast requirements:
- The focus indicator must have a contrast ratio ≥ 3:1 against the adjacent colors
- Focus styles set via
outline: none or outline: 0 without a replacement must be rejected
2. Color must not be the only indicator (color-vision deficiencies)
For every UI state or piece of information, we must verify that meaning is not conveyed by color alone.
2.1 Required non-color indicators
If color is used to express meaning (error, success, selected, focused, warning), then at least one of the following must also be present:
- Textual label
- Icon or symbol
- Shape, outline, or border change
- Pattern or positional change
2.2 Specific checks
- Error states must not rely solely on red
- Success states must not rely solely on green
- Selected or focused states must not rely solely on color changes
- Graphs and charts must combine:
- Color
- Labels and/or shapes
If a state is distinguishable only by color, the usage must be rejected.
3. Prefer simple colors (sensory sensitivity / autism)
3.1 Definition of acceptable colors
Colors are considered acceptable if they meet all of the following:
- Low to medium saturation
- Must not be near maximum saturation
- Moderate brightness
- Must avoid excessive use of pure white or pure black
- Moderate contrast
- Must remain readable without producing harsh visual separation
3.2 Palette constraints
We must verify:
- The base color palette is intentionally limited
- Each color has a documented semantic purpose
- Decorative colors without semantic meaning must not be introduced
- Most surfaces use neutral colors
- Accent colors are used sparingly and intentionally
3.3 Consistency rules
Across the entire application:
- A given color must always represent the same meaning
- A color must not represent conflicting states
- Neutral colors must not be reused as alert or error indicators
3.4 Prohibited color usage
The following usages must be rejected:
- Highly saturated or fluorescent colors
- Rapidly alternating or flashing colors
- Abrupt color changes that draw attention through intensity
- Color changes combined with motion or animation
- Visually complex color effects:
- Heavy gradients
- Patterns
- Color overlays
- Text placed over complex or multicolored backgrounds
- Visually "vibrating" color combinations:
- High-contrast complementary pairs (e.g. red on blue)
4. Dark theme requirement
All rules defined in sections 1, 2, and 3:
- Must be validated independently for light mode and dark mode
- A color that passes in light mode does not automatically pass in dark mode
- Theme-specific color tokens must be checked separately
5. Decision model
A color usage is acceptable if and only if:
- All applicable contrast thresholds are met
- Meaning is not conveyed by color alone
- Colors are simple, limited, consistent, and non-overstimulating
- All rules pass in both light and dark themes
If any rule fails, we must flag the usage as non-accessible.
