How to Add Colorblind Modes to Web Games

Step 1: Audit Your Game for Color-Only Information

Before writing any code, review every game element that uses color to communicate information. Common offenders include: team or faction colors on a minimap (red vs. green teams), health or status bars that change color at thresholds (green when full, yellow when half, red when low), item rarity borders or backgrounds (gray, green, blue, purple, orange, gold), interactive object highlights (green glow for usable, red glow for locked), danger zone indicators (red areas on the ground), resource types distinguished by color (red gems, green gems, blue gems), and error or success states (red for error, green for success).

For each element, ask: if I remove all color and display everything in grayscale, can the player still distinguish between the states? If not, that element has a color-only dependency and needs a fix. Document every instance. This audit becomes the checklist for the next step.

Step 2: Add Redundant Non-Color Indicators

For each color-only element identified in the audit, add a secondary indicator that works without color. This step is actually more important than a colorblind palette because it solves the problem universally, helping not only colorblind players but also players viewing screens in bright sunlight, players with miscalibrated monitors, and players who are unfamiliar with the game's color conventions.

Team markers: use shapes alongside colors (circles vs. triangles vs. squares). Health bars: display a numeric percentage alongside the color gradient, and change the bar's fill pattern (solid when full, striped when half, dotted when critical). Item rarities: add a text label (Common, Uncommon, Rare, Epic, Legendary) or a star rating alongside the color. Interactive highlights: use an icon (lock icon for locked, hand icon for interactable) alongside the color glow. Resource types: use distinct shapes or symbols (circle, diamond, hexagon) alongside different colors. Status effects: use icons (skull for poison, snowflake for frozen, flame for burning) rather than colored overlays alone.

These redundant indicators should be the default for all players, not hidden behind a colorblind mode toggle. They improve clarity for everyone and eliminate the need for colorblind players to self-identify by enabling a special mode for basic usability.

Step 3: Build a CSS Custom Property Palette System

For HTML/CSS game UI (menus, HUD overlays, settings screens, inventory, dialogue boxes), define all colors using CSS custom properties on the :root element. This creates a centralized palette that can be swapped entirely by changing variable values.

Define your default palette with properties like --color-team-a, --color-team-b, --color-health-full, --color-health-low, --color-danger, --color-safe, --color-interactive, and --color-locked. Then create alternate palette classes that override these values for each colorblind type. For deuteranopia and protanopia, the key change is replacing red-green distinctions with blue-orange distinctions, since blue-orange discrimination is preserved across all three CVD types. For tritanopia, replace blue-yellow distinctions with red-green distinctions (the reverse of the more common types).

Apply the palette by adding a class to the document root: document.documentElement.classList.add('cb-deuteranopia'). The CSS cascade handles the rest, updating all UI elements that reference the custom properties. This approach is performant (no JavaScript color calculations per frame), maintainable (all colors in one place), and extensible (adding a new colorblind type means adding a new class with overridden custom property values).

A universally safe default palette uses blue (#0072B2) and orange (#E69F00) as the primary contrast pair, with yellow (#F0E442), sky blue (#56B4E9), vermillion (#D55E00), reddish purple (#CC79A7), and bluish green (#009E73) as secondary colors. This palette, based on research by Masataka Okabe and Kei Ito, is distinguishable by people with all three types of color vision deficiency.

Step 4: Apply Canvas Color Matrix Filters for Game World Rendering

For canvas-rendered game content (the actual game world, sprites, tiles, and 3D scenes), CSS custom properties do not apply because the colors are baked into image assets and rendering pipelines. Instead, apply a color transformation that shifts the rendered output into a colorblind-safe range.

For 2D canvas games, a post-processing approach works: after rendering the frame to the canvas, read the pixel data with getImageData, apply a color transformation matrix to each pixel, and write it back with putImageData. The color matrix multiplies each pixel's RGB values by a 3x3 matrix that maps problematic colors to distinguishable alternatives. Precomputed matrices for each CVD type are available in accessibility research literature and open-source libraries like color-blind-filter.

For WebGL and 3D games, apply the color transformation as a full-screen post-processing shader. The fragment shader reads the rendered texture and applies the same color matrix multiplication. This runs on the GPU and has negligible performance impact compared to a CPU-side pixel manipulation approach. Most WebGL frameworks (Three.js, Babylon.js, PlayCanvas) support post-processing effects, making this straightforward to integrate. See the game shaders guide for more on post-processing pipelines.

An alternative to full-frame color transformation is recoloring game assets at load time. When a colorblind mode is active, swap sprite sheets or adjust texture colors during the loading phase rather than transforming every frame. This is more performant for games with many sprites but requires maintaining alternate asset versions or computing recolored versions on load.

Step 5: Test with Colorblind Simulation Tools

Chrome DevTools includes a built-in color vision deficiency simulator. Open DevTools, press Ctrl+Shift+P (Cmd+Shift+P on Mac) to open the command palette, type "rendering," select "Show Rendering," then scroll to the "Emulate vision deficiencies" dropdown. Select Deuteranopia, Protanopia, or Tritanopia to see your game through a simulated colorblind lens. This simulation is applied to the entire page, including canvas content, making it the most convenient testing tool for web games.

Test your game under each simulation mode and verify that: all team/faction distinctions are visible, health bar states are distinguishable, item rarities are identifiable, interactive objects stand out from non-interactive ones, and all gameplay-critical color cues have visible alternatives. If any distinction disappears under simulation, that element needs a fix, either a better color choice or an added non-color indicator.

Beyond Chrome DevTools, tools like the Colorblindly browser extension, the Color Oracle desktop application, and the Coblis online simulator provide additional testing options. The Firefox Accessibility Inspector also includes color simulation features. Test on at least two different tools to catch any discrepancies.

Step 6: Persist Settings and Provide Presets

Save the player's selected colorblind mode in localStorage so it persists across sessions. When the game loads, check localStorage for a saved preference and apply it before the first frame renders. This prevents a flash of default colors followed by a correction, which is disorienting.

Provide named presets in the settings menu: Normal (default palette), Deuteranopia (most common, green-weak), Protanopia (red-weak), Tritanopia (blue-weak, rare), and optionally High Contrast (a maximally distinguishable palette for severe CVD). Include a preview that shows the current game scene or a representative sample with the selected palette applied, so the player can compare modes before committing. Some players do not know their specific CVD type and will choose the mode that "looks right" by comparing previews.

Consider auto-detection as a convenience feature. While browsers do not expose color vision status, you can present a brief color test on first launch (a few pairs of colored dots, asking the player which look the same) to recommend a preset. This is entirely optional and should be skippable, but it helps players who do not know their CVD type and would not otherwise explore the colorblind settings.