fix(commons/color): Match browser behavior for out-of-gamut oklch colors#4908
Merged
straker merged 1 commit intodequelabs:developfrom Oct 13, 2025
Merged
fix(commons/color): Match browser behavior for out-of-gamut oklch colors#4908straker merged 1 commit intodequelabs:developfrom
straker merged 1 commit intodequelabs:developfrom
Conversation
While working on color-contrast accessibility in our own app we noticed that the contrasts calculated by axe-core were different from the ones we calculated ourselves, despite using the same colors that axe gave us in the data (fgColor, bgColor) for the color-contrast check results. The difference came from how out-of-gamut colors were handled. As an example, for color oklch(25% 0.75, 345) we got a color parsed to (roughly) r: 0.73 g: -0.44 b: 0.4 The negative green value here threw getContrast off. When troubleshooting we found that the `red`, `green` and `blue` values were the same ones the browser would give us for the same oklch input (186, 0, 103). To fix this, we can make use of the `toGamut` function of colorjs.io and ask for it to clip any out-of-gamut colors. This seems to be what browsers do as well, so this fix should make things align better with what developers see when working in a browser. Related issue for color.js: color-js/color.js#301
|
|
straker
approved these changes
Oct 13, 2025
straker
changed the title
Garbee
pushed a commit
that referenced
this pull request
Oct 31, 2025
…ors (#4908) While working on color-contrast accessibility in our own app we noticed that the contrasts calculated by axe-core were different from the ones we calculated ourselves, despite using the same colors that axe gave us in the data (fgColor, bgColor) for the color-contrast check results. The difference came from how out-of-gamut colors were handled. As an example, for color oklch(25% 0.75, 345) we got a color parsed to (roughly) r: 0.73 g: -0.44 b: 0.4 The negative green value here threw getContrast off. When troubleshooting we found that the `red`, `green` and `blue` values were the same ones the browser would give us for the same oklch input (186, 0, 103). To fix this, we can make use of the `toGamut` function of colorjs.io and ask for it to clip any out-of-gamut colors. This seems to be what browsers do as well, so this fix should make things align better with what developers see when working in a browser. Related issue for color.js: color-js/color.js#301
This was referenced Jan 5, 2026
WilcoFiers
added a commit
that referenced
this pull request
Jan 6, 2026
### [4.11.1](v4.11.0...v4.11.1) (2026-01-06) ### Bug Fixes - allow shadow roots in axe.run contexts ([#4952](#4952)) ([d4aee16](d4aee16)), closes [#4941](#4941) - color contrast fails for oklch and oklab with none ([#4959](#4959)) ([8f249fd](8f249fd)) - **color-contrast:** do not incomplete on textarea ([#4968](#4968)) ([d271788](d271788)), closes [#4947](#4947) - **commons/color:** Match browser behavior for out-of-gamut oklch colors ([#4908](#4908)) ([5036be8](5036be8)) - don't runs rules that select `html` on nested `html` elements ([#4969](#4969)) ([1e9a5c3](1e9a5c3)) - replaced luminance threshold constant 0.03928 with 0.04045 ([#4934](#4934)) ([316967d](316967d)), closes [#4933](#4933) - **rgaa:** adjust mapping of aria-hidden-\* and valid-lang ([#4935](#4935)) ([77571f2](77571f2)) - **valid-lang:** update valid-langs for newer language codes ([#4966](#4966)) ([c3f5446](c3f5446)), closes [#4963](#4963) This PR was opened by a robot 🤖 🎉
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While working on color-contrast accessibility in our own app we noticed that the contrasts calculated by axe-core were different from the ones we calculated ourselves, despite using the same colors that axe gave us in the data (fgColor, bgColor) for the color-contrast check results. The difference came from how out-of-gamut colors were handled.
As an example, for color oklch(25% 0.75, 345) we got a color parsed to (roughly)
r: 0.73
g: -0.44
b: 0.4
The negative green value here threw getContrast off. When troubleshooting we found that the
red,greenandbluevalues were the same ones the browser would give us for the same oklch input (186, 0, 103).To fix this, we can make use of the
toGamutfunction of colorjs.io and ask for it to clip any out-of-gamut colors. This seems to be what browsers do as well, so this fix should make things align better with what developers see when working in a browser.Related issue for color.js: color-js/color.js#301