ANDI fails large text with ratios > 3:1 about andi HOT 1 CLOSED

We fixed this issue (cANDI 3.2.2). Here is some additional info for future reference:

cANDI is certainly taking font size and weight into consideration. WCAG’s current requirement for large text, 14pt bold, is not exactly precise. Using the point (pt) unit is relevant to the font chosen and the user agent (OS/browser) doing the conversion into pixels. See this definition of large scale text from WCAG (especially note 3) http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#larger-scaledef. Therefore, all font size units (pt, em, %, etc.) are converted to px to perform the comparison.

A google search for “pt to px conversion”, returns only approximate figures. Some results show 14pt to be approximately 19px. Some calculators put it closer to 18.5px. Using Windows 10 both IE and Chrome are calculating 14pt to be 18 pixels (they may be rounding down). Since cANDI relies on the user agent to provide the computed unit (the pixel value), its cut-off was at 18.5pixels, which is why this github issue was created.

To resolve this issue, we adjusted the large text threshold to be 18px so that when testing against basic fonts on Windows 10 IE/Chrome/Firefox, the 3:1 ratio check will kick in. Keep in mind some user agents/fonts may convert 14pt to a different pixel value, which may show this type of issue again.

The underlying issue is with how WCAG defines large text. If it was defined using pixels instead of points, there would be no room for such discrepancies.

from andi.