Low vision is not the same as blindness, and designing for low vision is not the same as designing for screen reader users. This distinction matters because the two groups have different needs, and design approaches optimized for one can be unhelpful or actively counterproductive for the other.
Low vision refers to a range of visual impairments that significantly affect a person's ability to see even with corrective lenses, but where some functional vision remains. The causes are varied — macular degeneration, glaucoma, diabetic retinopathy, amblyopia — and the visual profiles they produce are also varied. Some low vision conditions affect central vision (blurring or blocking the center of the visual field while peripheral vision remains). Others affect contrast sensitivity without significantly affecting acuity. Others produce patchy or inconsistent visual fields. Designing for "low vision" as a monolithic category is an oversimplification — the reality is a spectrum of functional visual profiles that a single design approach cannot fully address.
What follows are the four principles we have settled on at Games4ALiving, after building two games with low vision design as a first-class concern.
Principle One: UI Separation from Game World
The most consistent need across low vision profiles is clear visual separation between game interface elements and the game world itself. For players with reduced contrast sensitivity or blurred central vision, interface elements that are composited over the game environment — health bars layered over terrain, text labels that float against moving backgrounds, icons that share visual characteristics with game objects — become extremely difficult to parse.
In Camins, we addressed this with a consistent visual layer separation. UI elements (path indicators, puzzle state counters, the undo button, accessibility menus) are displayed on a dedicated dark surface that maintains a minimum contrast ratio of 7:1 against the UI text and icons — exceeding WCAG's enhanced (AAA) threshold for text of 7:1. This surface is visually distinct from the game environment by design: the game world uses the warm Catalonian palette (ochre, terracotta, warm greens), while UI surfaces use the studio's dark navy (#1A1A2E) with cream text. There is no visual ambiguity about which layer an element belongs to.
The high contrast mode option goes further: when enabled, UI backing surfaces become pure black, text becomes pure white, and all decorative visual elements within the UI are suppressed. The game world itself shifts to a higher-contrast palette. The aesthetic changes significantly — it is a different visual experience — but it is a fully functional one.
Principle Two: Scalable UI With Layout Integrity
Most games offer a text size option. Fewer offer a UI scale option that adjusts all interface elements together. Fewer still ensure that the adjusted layout maintains functional integrity — that elements do not overlap, clip, or become inaccessible at larger scales.
We discussed the engineering of the Camins UI scale system in our piece on color contrast. The design principle underneath it is that the UI must be designed as a flexible system from the start, not as a fixed-dimension layout that an accessibility option stretches. This means designing with relative units and percentage-based constraints rather than fixed pixel values for container dimensions and text containers.
We're not saying every studio needs to implement a full fluid layout system for their game UI — the engineering cost is real, especially for smaller teams. We're saying that the decision to use fixed pixel values for UI layout is a choice that makes low vision support harder, and it is worth knowing that before making it.
Principle Three: Redundant Information Channels
A core principle of accessible design is that information should not be conveyed through a single sensory channel alone. For low vision players, the specific risk is that visual information they cannot reliably perceive is unavailable through any other channel.
In Camins, the key game state information — which paths are active, which puzzle conditions are met, what the current undo state is — is conveyed through both visual and audio channels. Active paths produce a soft ambient tone; the pitch shifts slightly as the player explores further from their starting point. Undo operations produce a distinct audio event. Puzzle completion produces a full audio cue that is unambiguous even if the player cannot clearly see the visual completion effect.
This redundancy serves multiple accessibility goals simultaneously — it is useful for deaf players if the channels are reversed (visual redundancy for audio information), for players in noisy environments, and for players whose attention shifts between visual channels. For low vision players specifically, it means that a missed or unclear visual cue does not necessarily mean missed game state information.
Principle Four: Interaction Target Size and Proximity
Low vision players — particularly those with reduced central acuity — may have difficulty targeting small interaction zones. They may also navigate with the screen closer to their eyes, changing the effective spatial relationships between elements.
The minimum touch and click target size in Camins is 48 logical pixels (larger than the 44px iOS and WCAG recommendation, which we treat as a floor not a target). The margins between interactive elements are sized so that activating one target does not risk activating an adjacent one — we call these "guard margins" in the design documentation, and they are defined as a percentage of target size rather than a fixed value so that they scale correctly when the UI scale option is adjusted.
The interaction zones for puzzle elements in the game world itself — the "landing areas" we mentioned in the motor accessibility article — also benefit low vision players: generous hit detection means that a player who cannot precisely target the visual center of an interaction point can still trigger it by pointing roughly at the right area.
The Gap We Have Not Closed
The most significant gap in our current low vision support is screen magnification compatibility. Players who use OS-level screen magnification (Windows Magnifier, macOS Zoom) to enlarge everything on their screen encounter layout problems in Camins that we have not yet resolved. The game's resolution and aspect ratio handling does not currently interact well with system magnification, which can cause UI elements to move off screen or become obscured.
This is a known issue in our backlog. The fix requires changes to the game's resolution and window management architecture — not a quick patch — and it affects a relatively small number of players compared to the in-game scaling option. We are naming it here because we think it is more useful to be honest about the gaps in our accessibility implementation than to describe only the parts that work.
Low vision design in games is not a solved problem, and any studio claiming full low vision support should be asked specific questions. What we have built is better than most games in our size class. It is not finished.