WCAG 2.1 Success Criterion 1.4.3 defines a minimum contrast ratio of 4.5:1 for text against its background (3:1 for large text). It is the single most widely cited visual accessibility standard in any kind of digital product, and it is a useful baseline. It is also — in the context of game design — an incomplete one.
This is not a criticism of WCAG. The Web Content Accessibility Guidelines were designed for web content, and they do their job well in that context. The problem is what happens when game designers treat WCAG's contrast criterion as the full scope of their visual accessibility obligation. It is not. The game interface exists in a context that WCAG was not designed to address, and understanding the gaps is essential to designing games that work for a wide range of players.
What WCAG's Contrast Ratio Measures — and What It Doesn't
The WCAG contrast ratio is calculated using relative luminance: a mathematical measure of how much light a color reflects, normalized to a scale from 0 (black) to 1 (white). The ratio between two colors' relative luminances determines whether they meet the minimum contrast threshold. This is a useful and defensible metric for determining whether text on a static, flat background is legible.
Games are not static flat backgrounds. The visual contexts in which game text and UI elements appear include:
- Moving, animated backgrounds (particle effects, parallax layers, dynamic lighting)
- Gradients and mixed-hue backgrounds where the contrast ratio shifts across the text's footprint
- Semi-transparent overlays that composite with variable-brightness content underneath
- Color-filtered scenes (fog effects, underwater tinting, night-vision modes) that alter the apparent contrast of UI elements
- High-motion contexts where text is displayed briefly and the player has limited time to focus
WCAG 1.4.3 does not address any of these. It was not designed to. When we designed the UI for Camins, we quickly found that elements passing the 4.5:1 static ratio became unreadable in specific in-game contexts — not because the colors were wrong in isolation, but because the game's visual environment created dynamic contrast interference that the ratio calculation could not predict.
The Animated Background Problem
In Camins, several scenes involve light filtering through foliage — a stylized effect where warm light patches move slowly across the landscape. We had designed a UI element (a small path indicator displayed in the corner of the screen) that met 4.5:1 contrast on the neutral stone terrain that covered most of the scene. When that element moved into the foliage zone, its effective contrast dropped significantly as the light patches swept behind it.
The solution we implemented was a drop shadow approach: a soft, semi-transparent dark halo around the UI element that guaranteed a minimum contrast irrespective of what was behind it. This is a known technique in game UI design — sometimes called a "text plate" or "UI backing" — and it is more reliable in dynamic contexts than a fixed contrast ratio calculation. The backing itself introduces a small visual weight, but the legibility gain is substantial.
We're not saying contrast ratio calculations are useless — they are not, and we still run every static UI element against a ratio calculator as a baseline check. We're saying that in game contexts, the calculation is a necessary starting point, not a sufficient one. The test that matters is whether the element is readable across the full range of dynamic contexts in which it will appear.
Colorblind Design Is Not Just Palette Swapping
WCAG 1.4.1 addresses the use of color alone to convey information — the guideline that information should not rely solely on color distinction to be understandable. This is a sound principle, and it is directly relevant to games.
The common implementation is a colorblind mode: a palette filter that shifts the game's color space to simulate or compensate for Protanopia, Deuteranopia, or Tritanopia. This is useful, and Camins and Pausa both have it. But colorblind modes that simply remap the palette without considering the game's information design can fail in interesting ways.
The specific failure mode is when a game's visual language is built around hue distinctions that collapse under colorblind simulation — where a red path and a green path that were designed to be distinct become indistinguishable under Deuteranopia, not because the colors are similar in absolute terms, but because the game's layout and composition put them in direct proximity at low saturation. A simple palette remap may not resolve this; the composition itself needs to work without relying on hue contrast.
In Camins, we redesigned two puzzle elements mid-development specifically because our colorblind testing revealed that they relied on a red-green hue distinction that a Deuteranopia simulation collapsed. The redesign used shape difference and pattern in addition to color — the two elements were given distinct visual textures that remained distinguishable under all three simulation modes. This required more visual work than a palette filter, but it produced a better outcome.
Low Vision and the UI Scaling Problem
WCAG Success Criterion 1.4.4 (Resize Text) requires that text can be resized up to 200% without loss of functionality. In web contexts this is about browser zoom. In game contexts, it raises a harder question: what happens to your UI layout when text is enlarged significantly?
Most games are built with a specific viewport in mind, and their UI layouts assume that text occupies a bounded amount of horizontal space. When text scales up — whether because a player needs larger type for low vision, or because the game is being played on a screen that is further away than the design assumed — the layout often breaks. Text overflows containers, buttons grow beyond their defined touch targets, labels obscure other elements.
Camins has a UI scale slider that runs from 50% to 200% of the default size. Building this required us to design the UI layout as a flexible system rather than a fixed layout — the containers scale with the text, the padding scales proportionally, and we tested at every major breakpoint (50%, 75%, 100%, 125%, 150%, 175%, 200%) to verify that the layout held and no information was lost. This is significantly more work than designing a single fixed layout, but for players who routinely need larger text, it is the difference between a playable and an unplayable game.
Motion Sensitivity and Dynamic Contrast
A dimension of visual accessibility that WCAG addresses only partially is motion sensitivity. WCAG 2.3.1 (Three Flashes or Below Threshold) targets photosensitive epilepsy specifically — content that flashes at certain frequencies. This is important and necessary. But motion sensitivity extends well beyond flicker thresholds.
Players with vestibular disorders, migraines, or certain neurological conditions can experience significant discomfort from smooth, constant motion — the kind of parallax scrolling, camera drift, and ambient animation that is standard in most contemporary game environments. Pausa's reduced motion mode was implemented specifically to address this. In standard mode, the game has slow, flowing visual animations. In reduced motion mode, those animations are substantially slowed and their amplitude is reduced, maintaining the visual character of the game while removing the motion that triggers discomfort for sensitive players.
What we found in practice was that reduced motion mode was not used only by players with vestibular conditions. Players who play late at night, players who are fatigued, players who simply prefer less visual movement all reached for the toggle. This is the universal design argument in miniature: features designed for specific accessibility needs often improve the experience for a broader range of players. The contrast ratio calculation is the beginning of visual accessibility thinking, not the end of it.