Methodology
Color-vision simulation model and limits
Color-vision simulation helps reveal palette risks, especially when color is the only cue. Hue Codex treats it as a screening tool, not a substitute for real user testing.
Short answer
Hue Codex applies fixed RGB transform matrices for protanopia, deuteranopia, tritanopia, and achromatopsia, then compares simulated swatches with Delta E style distance and WCAG-style text screening hints.
- The simulator approximates full dichromacy or full-condition views with fixed matrices; it is not a severity slider, anomalous-trichromacy model, or clinical model.
- Matrices are applied to gamma-encoded sRGB 0-255 channel values from HEX/CSS colors, not to linear-light RGB.
- Hue Codex does not currently implement the Brettel/Vienot/Mollon LMS projection model or the Machado/Oliveira/Fernandes severity-dependent physiological model.
- Pair risks are ranked by simulated Delta E distance, with closer pairs flagged for review.
- Best text recommendations on simulated colors are screening hints, not WCAG compliance claims.
- WCAG 1.4.1 Use of Color supports the rule that critical information needs a non-color cue when color communicates meaning or distinguishes an element.
- Simulation can reveal likely risks, but real accessibility still needs contrast, labels, icons, shape, position, and user context.
Standards status
These badges identify which parts of this methodology are standards-backed, draft-track, source-origin references, Hue Codex-specific, approximate, or dependent on browser behavior.
Formulas, choices, heuristics, and limits
This separates standards-based formulas from Hue Codex implementation decisions, product heuristics, and known limitations for this methodology.
Standards-based formulas
Formula, threshold, syntax, or data behavior taken from a cited standard. Primary and model sources can inform implementation, but they are not automatically standards.
- WCAG contrast math is reused for actual foreground/background contrast calculations.
- WCAG 1.4.1 Use of Color anchors the rule that color must not be the only visual means of communicating information or distinguishing an element.
- The cited WCAG guidance anchors the need for contrast and non-color cues.
Implementation choices
How Hue Codex chooses to parse, normalize, round, export, or sequence calculations.
- Hue Codex applies fixed RGB transform matrices for protanopia, deuteranopia, tritanopia, and achromatopsia.
- The current simulator is a fixed gamma-encoded sRGB matrix approximation; it applies matrices directly to 0-255 sRGB channel values from HEX/CSS colors, not to linear-light RGB.
- It does not implement Brettel/Vienot/Mollon LMS projection or Machado/Oliveira/Fernandes severity-dependent matrices.
- Simulated values are clamped back to displayable sRGB before downstream checks.
- Duplicate colors are removed before pair risk review.
Hue Codex heuristics
Product rankings, bands, labels, suggestions, or role hints that are useful guidance but not external standards.
- Collapse risk labels and hue-only risk rankings are Hue Codex screening heuristics.
- Delta E cutoffs below 4, 8, and 14 for pair risk are Hue Codex review bands, not clinical or WCAG thresholds.
- Recalculating WCAG-style contrast on simulated colors is a Hue Codex screening heuristic, not a WCAG compliance result.
- Best text recommendations on simulated colors are guidance for further review.
- Safer design pattern guidance translates simulation risk into practical review prompts for labels, icons, patterns, direct annotation, redundant encoding, and luminance ordering.
Known limitations
Caveats, edge cases, browser dependencies, approximations, or contexts the method does not prove.
- Simulation is approximate and represents full-condition screening views, not anomalous trichromacy, partial severity, or individual color-vision profiles.
- The model does not account for display calibration, viewing distance, lighting, eye conditions, or adaptation.
- WCAG contrast conformance is based on the actual rendered foreground and background colors, not on a simulated perception transform.
- Passing simulation checks does not prove accessibility; meaning still needs labels, shape, position, and context.
Representative automated fixture coverage
Hue Codex imports versioned JSON fixtures and tests the corresponding pure production functions directly. The groups below are the representative regression evidence most relevant to this methodology.
- Parsing fixtures: Accepted CSS color syntax, alpha behavior, clamping, invalid input, and out-of-gamut fallback cases. View the JSON fixtures.
- Conversion fixtures: sRGB, XYZ, Lab/LCH, OKLab/OKLCH conversion values, round trips, and precision boundaries. View the JSON fixtures.
- Export fixtures: Displayed-versus-exported values, parseable CSS and JSON, and safe allowlisted SVG output. View the JSON fixtures.
What a pass means. A passing group confirms the named vectors and tested properties still match the documented implementation. It does not prove every possible input, final browser rendering, full accessibility conformance, profile-aware print output, or every downstream export consumer.
Badge scope on this page
The page cites WCAG Use of Color as an accessibility standard, but the simulation matrices and simulated-risk outputs are not standards. Hue Codex uses local badges to keep those boundaries visible.
| Topic | Badge scope |
|---|---|
| Matrix simulation | Approximation / Hue Codex heuristic |
| Use of Color guidance | WCAG standard |
| Risk bands | Hue Codex heuristic |
Simulation modes
Hue Codex includes protanopia, deuteranopia, tritanopia, and achromatopsia modes. The selected matrix is applied to each sRGB color and the result is clamped back to displayable sRGB.
These modes approximate full dichromacy or full-condition views. They do not model anomalous trichromacy such as protanomaly, deuteranomaly, or tritanomaly, and they do not expose partial severity values or person-specific profiles.
Duplicate HEX values are removed before pair comparison so the review focuses on distinct palette entries.
Simulation matrices
These are the exact matrices used by the Color Blindness Simulator, organized by mode. Each source model is a Hue Codex-chosen fixed matrix approximation because the current implementation does not run a named Brettel/Vienot/Mollon or Machado/Oliveira/Fernandes algorithm.
The input domain for every mode is gamma-encoded 8-bit sRGB from HEX/CSS sRGB colors. The three matrix rows produce simulated red, green, and blue output channels.
Approximation. The source-model label names Hue Codex implementation status, not a clinical model family or external standard.
post_process(mode, hex):
rgb = hex_to_rgb(hex) # gamma-encoded sRGB 0..255
matrix = matrix_for_mode(mode)
simulated_rgb = matrix * rgb
clamped = clamp_each_channel(simulated_rgb, 0, 255)
simulated_hex = rgb_to_hex(round_each_channel(clamped))
pair_distances = delta_e_76(original_pairs, simulated_pairs)
return simulated_hex, pair_distances| Mode | Source model | Input domain | Matrix |
|---|---|---|---|
| Protanopia | Hue Codex fixed encoded-sRGB matrix approximation | Gamma-encoded sRGB 0-255 channel values | [0.567 0.433 0; 0.558 0.442 0; 0 0.242 0.758] |
| Deuteranopia | Hue Codex fixed encoded-sRGB matrix approximation | Gamma-encoded sRGB 0-255 channel values | [0.625 0.375 0; 0.700 0.300 0; 0 0.300 0.700] |
| Tritanopia | Hue Codex fixed encoded-sRGB matrix approximation | Gamma-encoded sRGB 0-255 channel values | [0.950 0.050 0; 0 0.433 0.567; 0 0.475 0.525] |
| Achromatopsia | Hue Codex fixed encoded-sRGB matrix approximation | Gamma-encoded sRGB 0-255 channel values | [0.299 0.587 0.114; 0.299 0.587 0.114; 0.299 0.587 0.114] |
Gamma-encoded sRGB domain
Hue Codex decodes a HEX color to its ordinary gamma-encoded sRGB channel values, applies the selected 3 by 3 matrix to those 0-255 values, then rounds and clamps the result back to displayable sRGB HEX.
Hue Codex does not first linearize the sRGB channels with the inverse sRGB transfer function, apply the matrix in linear RGB, and then re-encode to gamma-corrected sRGB.
This domain choice matters. The colorspace package documents the same distinction: older versions applied CVD transforms directly to gamma-corrected sRGB coordinates, while colorspace 2.1-0 added a linearized RGB default for its Machado-based matrices. Hue Codex currently follows the direct gamma-encoded sRGB path, so Hue Codex outputs should not be expected to match colorspace with linear = TRUE or a full Machado implementation.
Approximation. Changing the transform domain from gamma-encoded sRGB to linear RGB can change saturated colors such as red, purple, and orange. Hue Codex preserves its current gamma-encoded path for deterministic compatibility with the published matrices and test vectors.
Why these legacy matrices?
These fixed matrices are Hue Codex-chosen, legacy-style encoded-sRGB screening coefficients retained for deterministic, fast palette review and stable published vectors. They are not claimed to be clinically validated or equivalent to LMS-projection or severity-dependent models such as Brettel/Vienot/Mollon or Machado/Oliveira/Fernandes.
Hue Codex keeps them as its legacy compatibility model because they are fast, deterministic, client-side, and already define the simulator output, export reports, validation palettes, and expected HEX examples published on this site.
That is a product and reproducibility rationale, not a claim that the matrices are the best available color-vision science. They are useful for catching obvious hue-collapse risks in palettes, charts, and status colors, but they are lower fidelity than LMS projection models or severity-dependent physiological models.
Hue Codex therefore treats the matrices as an approximation and Hue Codex implementation choice. The page does not cite them as WCAG, CIE, Brettel/Vienot/Mollon, Machado/Oliveira/Fernandes, clinical, or user-specific matrices.
If Hue Codex adds a higher-fidelity simulation later, it should appear as a separate named model or a clearly versioned change. Silently replacing this matrix family would change existing share links, reports, validation fixtures, and user expectations.
Provenance. No external legacy matrix set is being asserted as the source for these coefficients. Their provenance is the Hue Codex implementation and its published validation fixtures, not a standards body or named CVD simulation paper.
| Question | Hue Codex position |
|---|---|
| Why not silently switch to Machado or Brettel-style output? | Those models would change simulated HEX results and require a different documented algorithm, input domain, and validation fixture set. |
| What are these matrices good for? | Quick deterministic screening for likely hue-collapse problems and for prompting redundant design cues. |
| What are they not good for? | Clinical diagnosis, severity estimation, individual viewer prediction, calibrated display proofing, or WCAG conformance claims. |
Model lineage and citation status
The current Hue Codex simulator is a fixed 3 by 3 encoded-sRGB matrix approximation. It is designed for fast palette screening and reproducible outputs, not for clinical diagnosis or calibrated prediction of an individual viewer.
Two widely cited color-vision simulation approaches are Brettel, Vienot, and Mollon, which model dichromat appearance through LMS-space projection, and Machado, Oliveira, and Fernandes, which provide a physiologically based model with severity-dependent matrices. Hue Codex cites these as reference models, but the current simulator does not implement either algorithm.
Because Hue Codex does not implement severity-dependent matrices, it should not be used to estimate anomalous trichromacy strength or to infer how a specific person sees a palette.
Because the active Hue Codex model is the simpler fixed-matrix approximation listed above, the matrix outputs should be read as approximate review signals. The references below substantiate the broader simulation-model landscape and the distinction between Hue Codex heuristics and higher-fidelity CVD models.
Approximation. The published Hue Codex matrices are implementation choices for screening. They are not WCAG requirements, CIE standards, Brettel/Vienot/Mollon matrices, Machado/Oliveira/Fernandes severity tables, anomalous-trichromacy simulations, or individual profiles.
Risk ranking
For each pair, Hue Codex calculates original Delta E 76 and simulated Delta E 76. The thresholds below 4, 8, and 14 are Hue Codex screening heuristics for palette review; they are not WCAG pass/fail thresholds, clinical categories, or medical measures of color-vision severity.
Hue-only risks are pairs that begin visually separated but become close under the selected simulation. These are especially important for charts, status indicators, and selected states.
Hue Codex heuristic. Use these bands to prioritize review. Do not present them as clinical diagnosis, user-specific perception, or accessibility conformance.
| Simulated Delta E 76 | Hue Codex label | Interpretation |
|---|---|---|
| Less than 4 | Likely collapse | Colors may become difficult to distinguish in the selected simulation. |
| At least 4 and less than 8 | Needs non-color cues | Add labels, icons, shape, position, underline, or other non-color signals. |
| At least 8 and less than 14 | Review in context | Check size, adjacency, task importance, and whether color is the only cue. |
| At least 14 | Distinct signal | Usually separated enough for screening, but still approximate and context-dependent. |
Text and contrast checks
Each simulated swatch receives a best black/white/text-candidate recommendation and a WCAG-style contrast calculation. This is a Hue Codex screening heuristic for review, not a WCAG compliance result.
WCAG contrast conformance is evaluated from the actual rendered foreground and background colors. A simulated-color contrast score can reveal possible risks after a perception transform, but it does not replace testing the real CSS/source color pair against WCAG thresholds.
Hue Codex heuristic. Simulated contrast checks help prioritize palette review. They should not be reported as WCAG AA, AAA, or non-text contrast conformance.
Use of Color guidance and safer design patterns
When a simulation shows possible color collapse, the recommended response is not simply to pick a different hue. Hue Codex treats color-vision simulation as a prompt to add redundant visual structure so meaning survives when hue separation is reduced.
WCAG 1.4.1 supports the baseline rule: color must not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing an element. The patterns below are Hue Codex implementation guidance for applying that rule in palettes, charts, status states, and design-system tokens.
Hue Codex heuristic. These patterns reduce common color-only failures, but they still need real component, chart, copy, size, contrast, and user-context review.
| Pattern | How to apply it | Why it helps |
|---|---|---|
| Labels | Place visible text near status chips, chart series, map regions, selected states, and validation messages instead of relying on swatch color alone. | The meaning remains available when two hues simulate as similar. |
| Icons | Pair status colors with stable symbols such as check, warning, error, info, locked, selected, or unavailable icons. | Shape carries meaning even when red/green or blue/yellow distinctions weaken. |
| Patterns and texture | Use dashed lines, dot fills, hatch marks, marker shapes, or texture variants for chart series, maps, heatmaps, and categorical fills. | A non-hue visual channel separates adjacent or overlapping marks. |
| Redundant encoding | Encode the same state with more than one cue: text plus icon, color plus position, line color plus dash style, or alert color plus heading copy. | Users do not have to decode the interface through a single fragile signal. |
| Direct annotation | Label chart lines, bars, thresholds, and important regions directly in the visualization rather than relying on a distant legend of small color chips. | The user can identify meaning at the point of use, even if legend colors collapse. |
| Luminance ordering | For sequential scales, make lightness move consistently from low to high; for diverging scales, keep both sides balanced around a clearly distinct center. | Order and magnitude can remain readable in grayscale or achromatopsia-style review. |
Limits
- The model approximates full dichromacy or full-condition views; it does not model anomalous trichromacy, partial severity, or individual color-vision profiles.
- The tool does not model display calibration, viewing distance, lighting, eye conditions, or individual adaptation.
- Recomputed contrast on simulated colors is advisory; WCAG compliance is based on actual rendered foreground/background colors.
- Passing simulation checks does not prove accessibility.
- Critical information should never depend on hue alone; WCAG 1.4.1 Use of Color requires another visual means when color conveys information, indicates an action, prompts a response, or distinguishes an element.
Validation palettes
These visible palettes are fixed review fixtures for common color-use patterns. They are not accessibility conformance tests by themselves; they help verify that the simulator still exposes likely risks in status colors, chart colors, ramps, and neutral systems.
Each expected row uses the same gamma-encoded sRGB matrix path documented above, then rounds and clamps the result to HEX. Labels are shown on neutral surfaces so saturated validation swatches do not rely on potentially low-contrast text placed directly on the color.
Hue Codex heuristic. A palette that looks acceptable in these fixtures can still fail in a real chart, alert, icon, map, or component if color is the only cue, marks are small, labels are missing, or foreground/background contrast is poor.
Red/green status colors
Use this fixture for success, danger, warning, and info states. The expected row uses deuteranopia, where red/green status meaning should receive icons, text, shape, or position cues.
Original status palette
Expected deuteranopia output
Sequential scale
Use this fixture to check whether a one-direction ramp still communicates order when hue is removed. The expected row uses achromatopsia.
Original blue ramp
Expected achromatopsia output
Diverging scale
Use this fixture for positive/negative or above/below-center scales. The expected row uses tritanopia, where blue/cyan and warm hues can shift in ways that need labels or direct values.
Original diverging ramp
Expected tritanopia output
Chart palette
Use this fixture for categorical chart series. The expected row uses deuteranopia and should be reviewed with direct labels, marker shapes, line styles, ordering, and tooltips.
Original chart series
Expected deuteranopia output
Neutral palette
Use this fixture to confirm that neutral systems remain mostly ordered by lightness. The expected row uses achromatopsia.
Original neutral scale
Expected achromatopsia output
Validation checks
| Check | Expected behavior |
|---|---|
| Two identical colors | Pair ranks as collapse risk |
| Red/green-heavy pairs in red-green modes | Review or collapse risk is likely |
| Achromatopsia mode | Output depends primarily on lightness |
| Export caveat | Reports state that simulation is approximate |
Simulation pseudocode
Hue Codex applies fixed matrices directly to encoded 8-bit sRGB channels, then rounds and clamps back to displayable sRGB. It does not linearize before these matrix transforms.
matrices:
protanopia =
[[0.567, 0.433, 0 ],
[0.558, 0.442, 0 ],
[0, 0.242, 0.758]]
deuteranopia =
[[0.625, 0.375, 0 ],
[0.700, 0.300, 0 ],
[0, 0.300, 0.7]]
tritanopia =
[[0.950, 0.050, 0 ],
[0, 0.433, 0.567],
[0, 0.475, 0.525]]
achromatopsia =
[[0.299, 0.587, 0.114],
[0.299, 0.587, 0.114],
[0.299, 0.587, 0.114]]
simulate(hex, matrix):
r, g, b = hex_to_rgb(hex) # encoded sRGB 0..255
r2 = r*matrix[0][0] + g*matrix[0][1] + b*matrix[0][2]
g2 = r*matrix[1][0] + g*matrix[1][1] + b*matrix[1][2]
b2 = r*matrix[2][0] + g*matrix[2][1] + b*matrix[2][2]
return rgb_to_hex(round_and_clamp(r2, g2, b2))
rank_pair_risks(colors, mode):
entries = unique colors mapped to simulated HEX
for each unordered pair:
original_delta = delta_e_76(original_a, original_b)
simulated_delta = delta_e_76(simulated_a, simulated_b)
# Hue Codex heuristic review bands, not WCAG or clinical thresholds.
label = simulated_delta < 4 ? collapse
: simulated_delta < 8 ? non_color_cues
: simulated_delta < 14 ? review
: distinct
sort pairs by simulated_delta ascending
hue_only_risk = original_delta >= 12 and simulated_delta < 8Reproducible test vectors
These vectors validate the fixed RGB transform matrices and final sRGB clamping used by the simulator.
| Input | Expected output | Notes |
|---|---|---|
| Protanopia matrix applied to #FF0000 | #918E00 | Matrix result rounded and clamped to sRGB |
| Deuteranopia matrix applied to #FF0000 | #9FB300 | Matrix result rounded and clamped to sRGB |
| Tritanopia matrix applied to #0000FF | #009186 | Matrix result rounded and clamped to sRGB |
| Achromatopsia matrix applied to #4169E1 | #6B6B6B | Equalized grayscale-style RGB result |
Sources and standards
These references anchor the public standards, model origins, source records, and formats used by Hue Codex. Status badges distinguish stable standards, drafts, primary sources, model sources, Hue Codex heuristics, approximations, and browser-dependent behavior.
Tools using this methodology
These Hue Codex tools link to this methodology because they depend on the formulas, assumptions, limits, or data policy described here.
Report a calculation issue
If a result does not match the documented formula or fixture, send the exact input, tool settings, displayed result, expected result, precision mode, and browser details. Please do not include private images, personal information, or secrets.