Representative color sampling for WCAG contrast: center pixel or area average #5115
-
|
I would like to ask about the recommended way to determine a “representative color” when using an eyedropper tool for WCAG contrast evaluation. Since WCAG does not specify how a sampled color should be obtained, which approach is considered more appropriate for practical accessibility testing? • Using the exact color of the center pixel I want to understand which method better reflects the color that users actually perceive, especially in cases involving anti‑aliasing, gradients, or soft edges. |
Beta Was this translation helpful? Give feedback.
Replies: 12 comments 3 replies
-
|
In my opinion, the best method is to zoom in far enough so that the centre of the letter, icon, frame, etc. is not affected by anti-aliasing, and then take the measurement at that centre point |
Beta Was this translation helpful? Give feedback.
-
|
WCAG explicitly states that you must use the colour specified by the author, so you should not be using a colour picker to obtain the text colour except for images of text. It's perfectly reasonable to measure the colour that users actually perceive, but that would not be part of a WCAG audit, so you can use any method you want. |
Beta Was this translation helpful? Give feedback.
-
|
@TestPartners Yes, that’s correct. If the contrast can be determined from the colours defined in the CSS, those should be used. However, there are many cases where this is not possible, not only with "images of text", but especially when testing SC 1.4.11 |
Beta Was this translation helpful? Give feedback.
-
|
I agree regarding SC 1.4.11, but the original question was about text, for which it is very rare that you can't determine the colour from the CSS. |
Beta Was this translation helpful? Give feedback.
-
|
@TestPartners I couldn't find any reference to text in the initial request... |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much for your thoughtful response. My question concerns WCAG 1.4.3 (Contrast Minimum) specifically for text that appears inside images. When evaluating the contrast between text color and background color within an image, tools that use an eyedropper must choose a method for determining the representative color of the text. Because text inside images is typically anti‑aliased and consists of multiple blended pixels, a single center pixel may not accurately represent the perceived color of the glyph. In contrast, a small averaged or median region (such as 5×5) may better reflect what users actually see. Therefore, I would like to ask: I am not seeking a normative requirement, but rather a practical recommendation or commonly accepted approach for tools that aim to align with the intent of WCAG. |
Beta Was this translation helpful? Give feedback.
-
|
This is an excellent refinement of your question. When specifically evaluating images of text (or text flattened into an image asset) under WCAG 1.4.3, anti-aliasing and subpixel rendering make a single-pixel approach mathematically volatile, whereas an averaged approach aligns far better with the intent of the guidelines. Mimics Human Perception: The human eye naturally blends and averages light across small areas. A single-pixel sample is highly volatile; moving your mouse by just one pixel on anti-aliased text can completely warp the color value and cause a false failure. Where to Sample: The area sample should be taken from the solid, dense core of the text stroke, intentionally avoiding the fuzzy, transitional edges created by anti-aliasing. The Background Rule: For the image background beneath the text, use a small area sample to find the "worst-case scenario" color (the area immediately adjacent to the text that offers the least amount of contrast). Industry Standard: Because the W3C does not dictate a normative requirement for eyedroppers, professional tools (like TPGi’s Colour Contrast Analyser) use magnification loops to help testers easily isolate and average these dense core colors. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks so much — this is extremely helpful. I’ll implement averaged sampling for text strokes and worst‑case sampling for |
Beta Was this translation helpful? Give feedback.
-
|
I think it is acceptable to select a point in the text that offers the highest contrast to the background, because the WCAG does not require sufficient contrast in the visual presentation even for standard text (outside images of text), but only a theoretical contrast defined in the CSS:
|
Beta Was this translation helpful? Give feedback.
-
|
The question is also what your aim is: do you want to achieve good accessibility? If so, choose contrasts that are visually sufficient, and then use parts of the letter that are relevant for recognising it (e.g. thin lines, but not serifs) for the measurement, even if these parts have lower contrast. Or do you want to check whether WCAG SC 1.4.3 is met? In that case, select the point with the highest contrast. However, if necessary, recommend increasing the contrast anyway if other parts of the letter do not have sufficient contrast. |
Beta Was this translation helpful? Give feedback.
-
|
If you're testing for WCAG conformance, you should not be using a colour picker, so your question is a non sequitur. WCAG states that you should get the text and background colours from the CSS. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your comment. However, if we assume that colors can always be obtained from CSS, it becomes difficult to account for the many cases that WCAG explicitly expects—such as text in videos, text embedded in images, gradients, transparency, blur effects, shadows functioning as outlines, and other situations where no single CSS-defined color exists. As Patrick and JAWS-test pointed out, in real-world testing scenarios CSS is often unavailable or insufficient, and using a color picker or similar method to determine representative colors is not only common but necessary. My question was therefore based on the practical application of WCAG in these non‑CSS scenarios. Declaring the question “logically incorrect” only makes sense if one assumes a much narrower set of conditions than those WCAG actually covers. Of course, when CSS colors are available, I fully agree that they should be used. |
Beta Was this translation helpful? Give feedback.
-
Unless you're testing something like text in a video, or text as part of an image ... |
Beta Was this translation helpful? Give feedback.
-
|
related: #3761 |
Beta Was this translation helpful? Give feedback.
-
There are many cases (apart from images of text, text in videos, etc.) where this isn’t so straightforward, e.g. if the text contains a colour gradient or is placed on one, if the text has transparency or CSS blur effects are applied, if the text itself does not have a colour that differs from the background, but has a shadow that serves as an outline, and many other cases where automatic contrast measurement tools fail and it is also difficult or impossible for humans to determine the contrast using CSS calculations. |
Beta Was this translation helpful? Give feedback.
This is an excellent refinement of your question. When specifically evaluating images of text (or text flattened into an image asset) under WCAG 1.4.3, anti-aliasing and subpixel rendering make a single-pixel approach mathematically volatile, whereas an averaged approach aligns far better with the intent of the guidelines.
The Practical Recommendation: A small averaged/median region (3×3 or 5×5 pixels) is considered the most reasonable approach for testing text inside images.
Mimics Human Perception: The human eye naturally blends and averages light across small areas. A single-pixel sample is highly volatile; moving your mouse by just one pixel on anti-aliased text can completely warp th…