APCA Use Cases and Conformance Research

[Myndex]

APCA KEY USE CASE DEFINITIONS

---

USE CASES CLARIFIED & RELATED CONDITIONALS (APCA)

It is of particular importance for complex information design to present a clear visual hierarchy, and the use of contrast variations is one of the important methods for doing so. As such, the definition of contrast requirements per use cases is the ideal means to achieve a reasonable guideline.

In WCAG 2, SC 1.4.3 attempted to achieve this with the claim of "3-way" contrast at 4.5:1 (#FF/#76, #76/#00), however this fails for several reasons.

• WCAG 2 is perceptually inaccurate, so #FF/On font weight (CSS, PANOSE) and accessibility #76 and On font weight (CSS, PANOSE) and accessibility #76/#00 are perceptually very different contrasts, the latter being unreadable.
• Such a blunt force guideline fails to provide for the nuances of a cogent visual hierarchy.
• In fact, an sRGB monitor does not have enough total contrast range for such a "3-way" when we are talking about small, thin text particularly body text.
• Even for cases of large text, the "3-way" paradigm as attempted in 1.4.3 does not lead to useful design guidelines.

WCAG 2 "Three Way" example:

^{Notice the darker pair is much less readable than the lighter pair. Click for full size}

Use Case By Functional Need

What we introduce with APCA is the concept of guidelines per use-case, and based on the functional need. For instance, the assumed functional need for columns of body text is a high quality of fluent readability, where the text can be read effortlessly, with minimal fatigue, and at maximum speed and comprehension.

At the other end of the spectrum is text for things such as placeholders, or disabled items, or copyright notices. It should be abundantly clear that such text has a much lower need for readability.

Making these distinctions among use cases is of critical importance, no merely for aesthetic design reasons, but for arranging the content within a visual hierarchy. This is particularly important for lexical, cognitive, and accessibility reasons of its own. A page of content with everything at the same size and contrast is difficult to read and access.

Good readability requires not only adequate contrast for the content text, but a layout and visual hierarchy that leads the user through the content in an accessible manner. APCA guidelines are intended to present a complete visual readability best practice.

USE CASE CLASSES and CONSIDERATIONS

The "fluent" category is divided into body text and non-body text, with the highest contrast reserve ascribed to body text, critical contrast of 18 times threshold at critical size, where threshold is a LogCS of ~1.3 or ~5% (roughly related to 20/70¹), or an APCA Lc 5. (1)^{It is important to note that acuity and contrast sensitivity are independent, despite what is stated in WCAG 2, which is notwithstanding here}).

Fluent text values assume a font sized at the critical size for the given contrast. Sub fluent levels permit smaller than critical font sizes.

• Fluent blocks of body text:
  • 18 times threshold (preferred)
  • 15 times threshold (minimum)
• Other fluent text:
  • 15 times threshold (preferred)
  • 12 times threshold (minimum for normal size)
  • 9 times threshold (minimum for large text)
• Sub-fluent content text:
  • 9 times threshold (minimum for small/normal sized
  • 6 times threshold (minimum for large)
• Sub-fluent non-content text:
  • 6 times threshold (minimum)²

(2)^{Bailey/Lovie-Kitchin define minimum spot reading at 3 times threshold, here we set that low bar only for certain non-text elements}).

Semantic & differentiable non-text requires a similar contrast relative to spatial frequency as "other fluent text". Merely discernible non-text is more equivelent to sub-fluent text.

• Intrinsically semantic (icon or pictogram, land map)
• Contextually semantic (chart lines, pie chart pieces, demographics map, lat/long lines, legend codes)
• Meta semantic (focus or state, dynamic driving map, animatable potentially in combination with 1 & 2)
• Discernible non-semantic (border, abstract button shape, map outer edge or legend area, zoom-up enlargement areas)

---

FLUENT

• Fluent Readability, Block/Body Text
  • Defined as:
    • a block or column of more than two continuous lines of text that:
    • uses a body font with an x-height of ~19px or LESS.
      • This means 34px Verdana or 42px Times (or smaller)
      • This is relative to the non-zoomed initial page load at 100%
      • MINIMUM font size: x-height of 9px (16px Verdana)
      • MINIMUM weight: 400 for fonts under 24px (x-height 12)
      • Minimum weight 300 for fonts above 24px.
      • MINIMUM contrast: Lc 75
      • PREFERRED contrast: Lc 90
    • is not a nav, menu, tool-tip, etc (those fall under fluent content)
  • slightly higher readability contrast/size is required for body text than other fluent content
  • is substantially impacted by line height and other whitespace contrast metrics
  • normally has the highest spatial frequency of any content on a page

ZOOM

- **ZOOM:** Body text has zoom priority over other adjacent text items.
    - When zooming *text* independently of other page items, body text should be the last text type to break or go into a horizintal scroll.
    - UNSETTLED: Should body text be the keystone text for zoom operations?
    - MORE WORK NEEDED: in terms of achievable guidelines on zoom amounts and relative zoom.

• Fluent Readability, Primary content that is not body text
  • up to two lines of continuous text (per the normal non-zoomed layout)
    • No larger than an x-height of 80px (Verdana 144px or Times 178px)
    • No smaller than an x-height of 8px (Verdana 14.4px or Times 17.8px)
    • MINIMUM weight: 300 for fonts under 24px (x-height 12)
    • Minimum weight 200 for fonts above 24px.
    • MINIMUM contrast of Lc 60
    • PREFERRED contrast: Lc 75
  • includes headlines, captions, and images of text, if they contribute to content
  • primary navigation and primary menus
  • asides, tool-tips, spoilers, "continued"
  • user entered text in forms, fields, etc
    - does not include text the user controls or adjusts in size or color

ZOOM

- **ZOOM:** Fluent text has zoom priority divisions (work needed)
    - RELATIVE: fluent content text that is normally larger than adjacent body text should _remain larger than body text when zooming,_ but the percentage of increase can and should be relaxed such that larger text does not increasein the same percentage as the smaller body text.
    - MORE WORK NEEDED: in terms of achievable guidelines on zoom amounts and relative zoom.

---

SPOT/ANCILLARY (non-fluent), SOFT (semi-fluent), and LARGE (fluent headlines)

Currently under consideration are the breakpoints for:
• "spot" readable non-content (disabled, placeholder, copyright)
• a subcategory of "soft content" that applies to certain aspects of dataviz (call-outs, de-enhanced aspects of visual hierarchy), and
• the subcategory of "large content" such as big, bold headlines which exist at a lower spatial frequency and require less contrast.

• Large Fluent header/title content

  • Minimum contrast is the as fluent lookup table, and relative to size/weight.
  • Very large bold headlines may have a minimum contrast of Lc 40.

• Soft Readability, small semi-fluent secondary/ancillary content

  • Needed for dataviz use cases
  • Must still be well above the legibility limit
  • Does not have to meet critical size nor critical contrast
    • No smaller than an x-height of 6.5px (Verdana 11.5px or Times 14.5px)
    • contrast no less than Lc 45 for x-height greater than 12px & 400 weight,
      • no less than Lc 60 otherwise
  • Category can include secondary/tertiary nav such as to TOS/EULA
  • This category may include byline, short duplicative captions, footer matter.

• Spot Readability, sub-fluent "non-content"

  • This category includes non-informative placeholder text on forms, and disabled controls.
  • Also copyright/trademark notices, license notices (but not actual license text blocks)
  • Must still be above the spot legibility limit (Lc 30)
  • Does not have to meet critical size nor critical contrast
    • No smaller than an x-height of 5px (Verdana 9px or Times 11px)
    • contrast no less than Lc 30

---

NON LEXICAL

• Non-Text Discernible Elements

  • Discernible means that while non-lexical, they carry specific meaning
  • Examples:
  • Emoji/color pictogram: ✈️ ❤️ 🚫 ⏮⏹▶️⏭⏏️ 🚴‍♀️ ☠️
  • Unicode ones: ☏ ☹⃠ ⇦ ⇨ ♘ ☜ ✇ ⃣
  • Solid vs outline require different contrasts, much like fonts: ♜♛♕♖♠︎♣︎♥︎♦︎♤♧♡♢
  • Coga issues: which is the home button? 🏚 ⌂
    • which is the hamburger menu? 🍔 ☰ ䷀
    • what are dots supposed to do if I click them? ⫶⃨
    • if I click this will I be happy? ☺︎
    • Is this radiation or a roll of recording tape? ☢︎
    • do I click this to call? ☎︎ Or does it just open a phone book?
    • Hey this one is hollow ☏ what does that mean? Is it supposed to be so much harder to see?

• Non-Text Functional Elements

  • button shape or form (not the text)
  • input field, forms, text areas (but no the text)
  • element focus and focusing indicators
  • inline link indication (but not the text itself which is separate)
  • meta states, visual user feedback (i.e. a blink on enter, etc).
  • temporal/spatial state changes (including state changes to text, separate from the text's contrast).
  • EXAMPLE: Buttons and WCAG2 vs WCAG3 APCA:
  • 
  • And that one single pass WCAG 2 did correctly, the background was a fairly high #b8b8b8, with black #000 text. In every other case, both the text and button were darker than #a0a0a0. The reason I mention this: one of the proposed SCs for WCAG 2 was "at least one color must remain above the equivalent of #a0a0a0". While it is not a perfect solution, it helps WCAG 2 avoid dark color pairs, where it is known to fail by incorrectly passing color pairs that shouldn't.

---

• Aesthetic and Divisional Elements
  • Simply anything that is purely decorative, non-readable, not needed for understanding content.
  • It can include contrasts that may be helpful for organizing content but are not strictly necessary.
  • These have no minimum contrast standard EXCEPT:
• Aesthetic and Divisional Elements SHALL NOT distract nor interfere with readable content.
  • GUIDANCE: avoid placing text on textured backgrounds.
  • GUIDANCE: take care to avoid placing decorative icons near functional (clickable) icons
    • EXAMPLE: is one of these the home button? 🏚 ⌂ 🏠🏡⌂⌂
    • EXAMPLE: when does a letter pictogram mean check email? ✉︎ 📬 📩 📨 📧 📥 📤 𖧕 𓊭 𓊭 ✉️ 💌
• If the aesthetic or divisional element helps a non-excluded element achieve a needed level of contrast, then the aesthetic element is not considered decorative, but is then grouped with the element type being helped.

EMPIRICAL BASIS FOR THE FOREGOING (IN PART):

Reading rate (wpm)	Minimum acuity reserve
Spot (∼40 wpm)	1.3:1 (0.1 log unit or 1 line*)
Fluent (≥100 wpm)	2:1 (0.3 log units or 3 lines*)
Maximum	3:1 to 8:1 (0.5 to 0.9 log units or 5–9 lines*)

Contrast Sensitivity vs Spatial Frequency

Per the following chart, we can see that spatial frequency drives contrast perception.

Here, various sizes of font and font weight are used for a practical demonstration. This premise applies to icons, pictograms, and other graphical elements as well.

Not shown is hue/chroma contrast, which is much lower in spatial frequency sensitivity, and peaks well below 1 cycle/degree. whereas luminance contrast peaks at at 2 - 3 cycles/degree.

---

"Normal" Vision Defined

Normal Vision is a specific definition, and a somewhat clinical definition:

• Snellen acuity of 20/20 or lower (20/16 is "perfect" acuity, 20/200 is SSA disabled)
• Peli-Robson contrast sensitivity of 1.95 or higher (2.25 is "best")
• Farnsworth Munsell Hue Color TES of 60 or less (TES 0 is perfect)
• 80% Visual field with MD no lower than -2db (0 is best, -20db is SSA disabled)
• The age-related baseline normal is ages 20 thru 40.
  • Below 20, contrast sensitivity is still developing, so young normal includes a lower contrast sensitivity.
  • Above 40, presbyopia is a normal development, so mature normal includes a lack of near-distance acuity.1

Footnotes:

• _The WHO sets average vision at 20/40. For the US, EU, Japan.
• Depending on the study, "normal" typically includes "with refractive correction" if the correction can achieve the required score.
  • An example: "normal with correction needed for presbyopia", presbyopia being "normal" for over age 40 for instance.
• SEE ALSO the SAPC Standard Observer Model_

copyright © 2019-2021 by Andrew Somers and Myndex Research™. All Rights Reserved.

---

---

Myndex Infographics

Critical Font Size

NOTE: review is ongoing in particular to align actual fonts to relevance with this table.

Physical Device Visual Angle per Distance

---

CITED RESEARCH (selects)

---

TERMS FROM RELATED RESEARCH OR STANDARDS

From Choeng/Lovie-Kitchin/Bailey/Bowers, also Legge, Arditi, Whittaker, and others. This includes some of the terms as commonly used in research.

• Acuity reserve The difference between the current print size and the smallest print size giving the maximum reading rate (critical print size) is the patient's acuity reserve. (AR as measured in lines is valid only when using a near-chart with a logarithmic progression of sizes in 0.1 log steps, such as Bailey–Lovie word or text charts or MNRead acuity charts.)
• Near visual acuity: the smallest print that can be resolved at the near test distance (example, 40 cm/16") indicates near visual acuity
• Text visual acuity (text VA): threshold print size
• Reading Rate (RR) in WPM: words per minute
• Maximum reading rate (MRR): the mean of the reading rates for print sizes at and above CPS
• Standard word: A standard word is six characters.
• WPM: words per minute
• Print size (N point, Lovie-Kitchin definition) Point measurement refers to the overall dimension of the type body from the top of the ascending letters to the bottom of the descending letters, with the lower case letters being half the point size; 1 point = 1/72 inch (0.35 mm). Point sizes are commonly preceded by N, for example, N8 (8 point print), which was first used by Law simply to indicate ‘near’.
• Critical print size (CPS): the smallest print size that gives maximum reading rate
• The M print size notation refers to the distance in meters, at which the overall size of the lower case letters subtends a visual angle of five minutes of arc.

---

-----

-----

-----

FOOTNOTES

• This first post may be edited periodically.

• When discussing the areas of vision and readability, there are a few terms that are important, which while they are used in research are not generally used in accessibility. However they are increasingly important to know as modern vision research makes its way into accessibility.

• On the Visual Contrast Wiki, the RESOURCES PAGE has a glossary and definitions, mostly they are the terms used in vision research or in colorimetry.

• Here I am going to try to limit to only those terms directly relating to readability.

• LOW VISION

  • LEGGE: low vision patients needed magnification that gave at least five times threshold size and a five-character field of view was sufficient.

---

---

---

TERMINOLOGY EMERGING FROM SAPC/APCA RESEARCH

This was moved to a new post below

[Myndex]

From the current APCA tool page:

Accessible Contrast

Relative to Font Size and Weight

The table below is current as of January 2022, though as this is a public beta, there may be occasional discrepancies with the above automated font display above.

GENERAL GUIDELINES on LEVELS

These general levels are appropriate for use without reference to the lookup table.

• 90 • Preferred level for fluent text and columns of body text with a font no smaller than 14px, or non-body text with a font no smaller than 12px. Also a recommended minimum for extremely thin fonts (light weight) of any size. Lc 90 is a suggested maximum for very large and bold fonts (greater than 36px bold), and large areas of color. This level is similar to ISO 10:1.
• 75 • The minimum level for columns of body text with a font no smaller than 18px, or non-body text with a font no smaller than 14px. Also, should be used for any text where readability is important. This level is functionally similar to 6:1 ~ 7:1 relative to WCAG2.
• 60 • The minimum level recommended for readable content text, that is, text you want people to read, and no smaller than 16px, and not used as body text. This level is functionally similar to the old 4.5:1 in WCAG2.
• 45 • The minimum for larger text (larger than 24px normal weight or 19px bold) such as headlines, and large text that should be fluently readable. This is also the minimum for pictograms with fine details, or smaller outline icons. This level is functionally similar to the old 3:1 in WCAG2.
• 30 • The absolute minimum for any text regardless of size or weight, including text for spot reading such as placeholder text, disabled element text, copyright, etc. Also the minimum for "understandable" or "uniquely identifiable" non-text elements such as "mostly solid" icons or bold pictograms, and controls or focus with a minimum dimension of 4px on the shortest area. This is the minimum for controls such as radio buttons or checkboxes, provided they are of sufficient size and thickness.
• 15 • The absolute minimum for any non-text that needs to be discernible and differentiable, such as dividers, and in some cases form outlines, but more for disabled elements, such as a disabled submit button — and this applies to the button shape and not the text (text of a disabled element is Lc30). Designers should treat anything below this level as invisible, as it will not be visible for many users. This minimum level should be avoided for items important to the use or interaction of the site. The range from Lc15 to Lc30 should be approached carefully and never used for elements that are critical to a task, such as a checkbox or radio button, except when they are in a "disabled" state.

NOTES ON FONT SIZE

Font sizes listed above assume an x-height ratio of at least 0.5. Font weight is based on highly standardized reference fonts such as Helvetica or Arial. "px" means the CSS reference px not device pixels. The reference px is defined as 1.278 arc minutes of visual angle.

NOTES ON WCAG_2 COMPATIBILITY

To use the APCA tool for minimum Bridge-PCA conformance (backwards compatible for WCAG_2):

• 90 • Lc 90 replaces WCAG_2 7:1
• 75 • Lc 75 replaces WCAG_2 4.5:1
• 60 • Lc 60 replaces WCAG_2 3:1
• WoB • For light text on a darker background, when the text is lighter than #eee, increase the minimum value by Lc 10. The dedicated Bridge-PCA tool takes this into account automatically.

Using the Lookup Table

• Cross index reference font size (in CSS px) to CSS weight.
• Reference fonts for comparison include Helvetica Neue, Helvetica, K2D, Fira Sans, Kanit, and Arial.
• APCA Contrast Lc value must meet or exceed the value listed, however, values may be interpolated between the two closest values.
• For light text on a dark background the APCA tool will show a negative Lc value. Simply use the absolute (positive) value. For example, if the APCA value is Lc-58, use Lc58.
• A ⊘ indicates that a larger font size (or heavier font weight) must be used.
• Cells marked with ^B may be used for body text. If the indicated contrast is lower that Lc 75, then add lc 15 to this minimum, OR increase up to Lc 75.

---

Font Lookup Table

---

About the colors in these tables:

The colors in these tables are designed to be discernible by all forms of color vision deficiency.

• The warning colors are grouped in a hue category that separates them from other colors for all CVD types.
• Important color codes also have a symbol such as ×, as color should never be the only coding for important information.
• Less important codes are directly related to the cell content, such as level 60, thus are self-symbolized.

Additional Notes

• Values shown are for common sans-serif fonts (e.g., Helvetica, Arial, Verdana, Montserrat, Roboto, Calibri, Trebuchet).
• Fonts should be compared in terms of x-height. For instance Times New Roman has an x-height of 0.45 compared to Helvetica's 0.52, thus Times New Roman must be set larger for equivelent x-height.
• Decorative, unusual, and very thin fonts should be avoided for columns of body text.
• Due to the vast variety of font designs, designers should visually compare an unusual font to a standard font such as Helvetica, using the size and weight of Helvetica that most closesly matches the appearance of the tested font as a guide.
• Designers are cautioned that bypassing default font smoothing can drastically reduce contrast for small or thin fonts. For instance, the use of "webkit-font-smoothing: antialiasing" is strongly discouraged.

---

Other guidance


[Myndex]

Non Text Categorization

This is something that's been on my mind lately, as I've been thinking of irreducible base categorization for non-text design guidance:

Four broad categories

These four categories have a similar hierarchal need of contrast as does body text followed by fluent text followed by spot text followed by ancillary text.

Each of these categories is distinct enough to have different design guidance needs.

1. Intrinsically semantic (icon or pictogram, land map)
2. Contextually semantic (chart lines, pie chart pieces, demographics map, lat/long lines, legend codes)
3. Meta semantic (focus or state, dynamic driving map, animatable potentially in combination with 1 & 2)
4. Discernible non-semantic (border, abstract button shape, map outer edge or legend area, zoom-up enlargement areas)

Uniqueness of #3

Of these, number three, meta, such as a focus indicator or a status light, may be a subcategory of #2, but I'm leaning away from that increasingly. Number three meta would seem to include:

• inline text links
• focus indicators
• available/disabled control or button indication
• A highlight of a #1 or #2 element, or an animation of a 1 or 2 element.

The reason #3 is unique is that some animatable property is always involved, even if only the most simple "on/off". An element where in change is inseparable from its function has unique design needs compared to purely static elements. This, and the fact that number three can be added to or used in combination with number one or number two, indicates it should be it's own category.

[alexkrolick]

Having some guidance on focus state contrast would be good, to answer questions like:

• To what should the focus color be compared, i.e., if you change a border color, should the contrast be against the previous color, or against the background. If you add a focus ring around an existing element, should the contrast be against the element or the background?
• Minimum weights and thicknesses for focus indicators

[bruce-usab]

I think it makes sense to distinguish, at least for now, Intrinsically semantic (icon or pictogram, land map). The others, should be able to lump together under a generic non text contrast category.

WCAG 2.2 should have a requirement for focus indicator that APCA can build on. Recent version is here: https://raw.githack.com/w3c/wcag/focus-appearance-rework/understanding/22/focus-appearance-minimum.html

[Myndex]

This post was moved to #104

If you followed a link here, please let the linker know the link changed

TERMINOLOGY EMERGING FROM SAPC/APCA RESEARCH

Old post contents hidden here

This was moved from the first post above to make it easier to link to:

In the course of research here, we have a few terms that are specific to the use case(s) and I'd like to clearly define them. These terms were created in the interest of clear and plain terminology that is descriptive and easily understood with little to no special explanation. I.e. the terms themselves are intended to be easy to grok, to help keep things simple, short, and digestible. (Some of the definitions need to be reworked, and moreover, visual aides created.)

COLOR and LIGHT

• Field Adaptation or alternately screen adaptation: When viewing self-illuminated displays, field adaptation refers to the light adaptation as a result of the total screen luminance, which is a peripheral adaptation, larger than the local adaptation of text and adjacent background, and smaller than the global/ambient adaptation.

• Y_s
  Estimated Screen Luminance — Y_s means the adjusted relative luminance of the display screen in the SAPC standard observer environment. This is similar to Y of XYZ. Y_s however, it may have modifications for a particular colorspace or vision accommodation.

• L^s
  Screen Lightness — L^s means the perceived lightness/darkness of the display screen in the standard observer environment. This is similar to L^* (Lstar) of CIELAB and CIELUV. L^s is part of the SAPC/SACAM model.

• L^c
  Lightness/Darkness Contrast — L^c or "Lightness Contrast" is the perceptual lightness contrast value generated by the APCA algorithm, based on achromatic luminance. Lightness Contrast is engineered to follow human supra-threshold perceived contrast of two elements of different luminances, and for specific spatial frequencies.

• H^c
  Perceived Color Contrast — this refers to the hue/chroma/saturation differences between colors, irrespective of lightness, and recognizing that spatial frequency affects hue markedly different than luminance (i.e. 1/3rd the resolution of luminance).

• C∩
  Color Set — beyond measuring a simple color pair, a color set is the color pair, and also the larger page background, larger page RMS contrast, and the ambient environment (and in some cases additional stimuli).

TEXT SIZE and CONTRAST

• Readability Size — Readability size is a combination of the fluent critical font size (relative to visual angle) at or above the critical contrast (in the standard observer environment) in the given use case, using L^c.

• Readability Contrast — Readability contrast is a combination of the critical contrast (using L^c) in conjuction with the font's critical weight, and at or above the critical font size (or element size) for a given use case.

  • Regarding Critical Size and Contrast
    • See Bailey/Lovie-Kitchin for the definitions of critical size and critical contrast—these terms mean the nexus point wherein increasing further does not result in an improvement in reading speed nor comprehension.

• Critical Weight — the font weight, or element thickness, needed to achieve a specific critical contrast level for a given color set.

• Weight Contrast — this defines the contrast of high spatial frequency items, especially stimuli that have a stroke width less than 4px. It applies to fonts and any "stroke type" stimuli.

  • The weight contrast of stimuli thicker than 4px, or a visual angle of 5 arc minutes, is fairly constant supra-threshold (contrast constancy).
  • The weight contrast of thinner stimuli are relatively more affected by spatial frequency than by luminance.
    • NOTE: in the world of typography, there is the term "font contrast" but this does not mean the contrast against a background, it means the contrast of the thicker strokes against the thinner strokes within a glyph.

PAGE and LAYOUT

• Whitespace Contrast Effect — refers to the readability contrast increase caused by increasing whitespace (line spacing, letter spacing, etc....)

• Page Font — a specific font face as actually used on a page of content. There may be several different page fonts on a page.

• WCAG 3 Reference Font or APCA Reference Font — a specific defined reference font face that is used for comparison to a desired page font, to determine offsets or ratios for specific font metrics, most importantly weight and x-height.

• Equivalent Readability Size (ERS) — A Ratio (or offset), of the difference in x-height of a specific Page Font relative to the x-height of a WCAG3 or APCA reference font. (For all uppercase fonts, then relative to the uppercase X height).

• Equivalent Readability Weight Ratio (ERW) — Ratio (or offset), the difference in perceived weight contrast, measured in L^c, of a specific page font relative to the weight contrast of a WCAG3 or APCA reference font.

USER PERSONALIZATION

• WoB (White on Black text or "Reverse") — Light text on a darker background, results in a negative L^c value (APCA).

  • Edit: this is now popularly being referred to as "dark mode"

• BoW (Black on White text or "Normal") — Dark text on a lighter background, results in a positive L^c value (APCA).

  • Edit: this is now popularly being referred to as "light mode"

• HiCon — a high contrast mode, where the standard colors on a page have increased distance. IMPORTANTLY, APCA guidelines suggest that smaller thinner text elements are given greater contrast increased than large bold thick elements (which in some cases should not be increased).

• LoCon — a lowered contrast mode, where the standard colors on a page have decreased distance.IMPORTANTLY, APCA guidelines suggest that large bold thick elements are given greater contrast decreases than smaller thinner text elements, such as body text (which often shold not be reduced).

• FlexZoom or Proportional Zoom — zooming textup to specific sizes, and not by a uniform percentage. I.e. the smallest text zoomes the most, the lagest text zooms by a smaller percentage, and only to maintain "being larger" but not by the sam proportions. This recognizes that there is a limit to how large a large font shold be zoomed.

---

[PSKuddel]

Hello, after quite some research as a complete beginner in everything regarding colors, I stumbled over this Myndex repository with lots of new information for me.

I have been trying to achieve my goal of automatically and consistently creating (at least more or less) perceptually linear bit by bit lighter or darker shades of a random color, instead of having to find recognizable small changes in shade manually by trial and error in some regular color picker, but wasn't successful so far. I started this whole "journey" like probably any complete beginner with no knowledge in the RGB color space using the HSV model, then I learned about blending, then I learned about gamma correction, then I learned about luminance, then I learned about contrast ratio. Still, no success was in sight, so then I learned about bigger color spaces and the XYZ color space and I learned, that my goal should be possible to achieve with the LAB color model.

Therefore, I now meanwhile have some working code, that - according to different color conversion calculators - can correctly represent and transform any RGB/HSV color into the corresponding LAB/LCH value and can also correctly calculate relative luminance and contrast ratio according to web standards. I now thought, that in this model I could just increase lightness in equidistant steps to receive perceived gradually lighter shades of grey (to start with), but the result was unfortunately underwhelming.

I tried to increase lightness in the LCH model in equal steps and in percentage increases, and I also tried to decrease contrast ratio against the background and against the previous darker shade in percentage steps, but still can't closely recreate my manual result.

Therefore, I would like to ask, if you could give me some hint, into which direction I would not have to extend my research to achieve my goal?

[Myndex]

Hi @PSKuddel

First, my sincere apologies in the long delay in responding to your message. This probably would've been better as its own separate thread, nevertheless I'm sorry that it slipped through the cracks.

First of all, what you're looking for is a perceptually uniform color appearance model. XYZ is linear to light and as a result is not perceptually uniform. LAB (and the related LCHab) was an attempt to create a perceptually uniform model, but it's lacking in a few areas, though is still useful and in substantial use today in industrial applications, as it is fairly good for calculating very small differences in color.

HSV is not at all uniform. As far as contrast ratio, if you're referring to WCAG2, it is not at all perceptual uniform. As such they should not be used in an automated context. We're out of any tools you need perceptual uniformity.

OKlab is a bit better than CIELAB. L* as a perceptual lightness correlate is based on muscle value which refers to diffusely reflecting large patches of paint in a very defined environment. L* does not seem to work as well on self illuminated displays.

Also, color difference is not the same as perceived contrast. ∆L*, i.e. the Lstar difference does not necessarily provide a perceptually uniform contrast measure or design elements such as text. SACAM which we have been working on is not ready for release, but you might find CAM16 interesting, or J_za_zb_z for instance.

I'm not certain if that answers your question but please feel free to ask further, you may want to start a new thread as this does not directly apply to this thread.

[PSKuddel]

Thanks for your reply, if I understand you correctly, there is no really perceptual uniform color model, where I can just mathematically create visually equidistant differences in lightness for any color (or at least shades of grey).

This is in line with my current understanding and would back, what the creators of Tailwind CSS wrote in their book „Refactoring UI“ about their manually selected color shades, as they also say, that after testing all kinds of color models, they came to the conclusion, that no color model can mathematically match a manual selection to create perceived equidistant shades.

[Myndex]

There are definitely models that can do this, but it's not nearly as simple as that. And even if you were to pick shades manually, when you came back to them days later you might be shocked to find that they don't seem to be what you thought you "picked".

Take a look at this image, it's one of my favorite illusions.

The colored dots that are under the shadow are giving out the exact same color from your monitor as the similar colored dots that are not in the shadow, and the same is true for the squares those dots are on. But for most people the colored dots under the shadow look as if they are glowing brighter, and the square that those dots are all on appears to be white/light, whereas the square that is not in the shadow appears to be a dark square.

Here's that same image again but with some graphic bars laid across from inside to outside of the shadow, to demonstrate that the colors are in fact identical.

And here you may notice an interesting phenomenon: on the grey bars as they go out of the shadow, it might appear the grey bars have a gradient on them making them darker as they cross the shadow threshold.

But there is no gradient—if you take an eyedropper tool and sample, you'll see the colors are in fact identical. The gradient on the bar is an illusion created in your brain as the bar goes out of the shadow.

---

So, the issue is our vision is so very context sensitive that a color model needs to have inputs not just for a pair of colors but for all of the surrounding colors we need to take into account all of the context in order to predict how it is going to appear.

Some color appearance models are fairly complete and do provide those additional inputs. There are versions of APCA/SACAM which have multiple inputs for these reasons. The APCA that's currently public facing only takes a pair of colors, with a number of assumptions made in terms of the common operating environment.

Keep in mind that color models are based on empirical studies and data collection of people's observations under controlled circumstances, so it's certainly possible to have models that fit within a particular set of circumstances.

[PSKuddel]

Thanks for the additional input, the surrounding context is no issue for me and I actually understand that already, that the same color would be perceived differently in a different surrounding context, so that is something I would not challenge anyway.

But my issue is only about creating perceived equidistant colors within a uniform context (so the whole background is evenly either white, or black or grey or blue or whatever) and here I can definitely create fine nuances of colored spots or lines on this uniform background manually, that seem equidistant in lightness and still seem equidistant in lightness the next day and the next week.

Is there a color model, that can produce perceived equidistant results under these conditions of a uniform background?

[Myndex]

Yes but....

SACAM is such a model, but it is not in release yet. Most other models deal with diffusely reflective large patches (i.e. paint samples). One thing that has that issue is the coefficient that are needed for use with a self illuminated display or device like a phone or a little bit different than those needed for diffuse patches of paint.

Part of the surrounding context I'm talking about is the gradient itself, and it matters if you're doing a continuous gradient or a step gradient. I had a couple of very old articles that compared a few different color models for a gradient use using step gradients, and they are on the myndex.com site, but they're kinda old, and I haven't updated them to the latest that we've been working on, and importantly the discussion didn't get into the more advanced models.

I do however have this Github repo called "fancy font flipping", and the code creates a ton of stepwise gradients with different power curves to experiment with—you might find that helpful. There's also a live webpage and a codepen: fancy font flipping

[Myndex]

This post was moved to it's own thread at #103

Defining Requirements for a Complete Visual Contrast Guideline

This week marks the three year anniversary of "thread #695" and also in view of the recent discussions and comparisons, I've prepared this outline that lists the specific problems with WCAG 2 contrast, and then outlines "what is needed" in an idealized contrast guideline.

Comments and thoughts welcome, (see new thread please)

Old post contents hidden here

WCAG 2 Contrast — Key Failure Points

• Perceptually inaccurate
  • When text is WHITE, then WCAG 2 math under-rates the contrast. (incorrectly fails colors)
  • When either color is BLACK, then then WCAG 2 math severely over-rates the contrast. (incorrectly passes colors)
  • Through the middle ranges (#76 to #a3), WCAG 2 is incorrect in determining when to flip from black to white text.
    • the fact the contrast midpoint is incorrect makes the claim of "three way contrast" spurious.
• WCAG 2 ignores contrast polarity and can not be used to calculate dark mode.
• WCAG 2 dismisses anti-aliasing effects, including author selected AA.
• WCAG 2 has a single breakpoint for text size, and therefore does not consider the important effects of spatial frequency.
  • the breakpoint as stated (at 24px normal and 18.7px bold) is not aligned with the contrast sensitivity curve.
  • the text size breakpoint is derived from physical "large print" and not related to spatial contrast effects.
• WCAG 2 does not define a minimum font size (other than the large text breakpoint).
• Font size and spacing specs in WCAG 2 rely on font metrics which are not consistent per family.
• WCAG 2 does not consider use cases, other than permitting certain complete exceptions
  • some Incidental, disabled, or decorative text.
  • corporate logos.
  • complete exceptions to many of these are inappropriate.
• Spatial frequency is ignored by 1.4.11 non-text, an area where designers especially need guidance.
  • 1.4.11 as written has no scientific basis nor evidentiary support.
  • The cited references are self-referential, out of context, or with qualifications ignored.
• WCAG 2 conflates readability contrast with discernibility contrast, when they should be considered separately.
• No padding or margin definitions

---

What Is Needed In a Complete Visual Contrast Guideline

Science (empirically based models)

• Developed based in modern vision science & readability science
  • Text use cases based on critical size and critical contrast, per Bailey/Lovie-Kitchin
• Math model that is uniform to human perception of contrast
  • Said uniformity to be sensitive to spatial frequency effects (weight/size/thickness)
  • Said uniformity to be sensitive to light and dark mode polarities
• Considers important aspects of text on a device or computer display
  • Guidance for Antialiasing and rasterizing issues (i.e. no smoothing small fonts)
  • Common monitor mis-adjustment and ambient/environment issues
  • Whole page luminance factors (at least estimated as per worst expected case)
• Defines a standardized observer environment.
  • To be used as a foundation for testing and evaluations
  • Specified observers for various impairment and vision types

---

Spatial Frequency (size, weight, spacing, zoom)

• Defines sizing guidance based on x-height per expected visual angle (CSS ref px)

  • Font sizing relative to x-height for body text and mixed case text.
    • Cap height used for upper case only text, or single-case writing systems.
  • Layout metrics such as leading (line height) and padding relative to x-height (not font body)
  • Kerning: per metrics or optical.
  • Tracking/letterspacing/indentations relative per x-height & glyph aspect ratio

• Font weights 100 to 900 defined with standard reference font.¹

  • Author fonts to use a weight offset, determined by comparison to standard reference font.
  • For latin, the primary reference is a sans-serif font with consistent stroke width, 0.5 x-height ratio.
  • Secondary reference fonts for serif, trans-serif, slab-serif, monospaced sans, and mono typewriter
  • Tertiary reference fonts for display, dingbat, ornamental.

• Provides design flexibility by dividing readability into appropriate use cases²

  • Body text needs near-maximum contrast for readability.
  • Fluent content text needs high contrast, but relaxed slightly from body text.
  • Soft-content text for dataviz needs, "important" footer matter (contact us, etc)
    • Soft content has relaxed size and contrast, similar in quality to 1.4.3
  • Spot readable text for disabled controls, placeholder, copyright, etc.
  • Layout characteristics and use of whitespace and information organization needs to be discussed at least as a "should."

• Technology for zooming, reflow

  • functional zooming & reflow is more of a browser technology problem, than an author issue, other than authors must be prohibited from blocking people from zooming.
  • what is needed are browsers that zoom not by a percentage for all fonts, but to a specific size for the smallest fonts with larger fonts zooming at smaller percentages percentages to prevent from overrun and allow larger overall zoom sizes.
  • maximum required zoom size is therefore based on x-height in px, with limits based on display device.

• Zoom examples in practice. For the following examples, let's assume that our default size body text is 16px Verdana, and we have a 36px headline in Barlow. Then let's compare a regular desktop screen and a mobile phone in portrait mode, the two extremes of display device size.

  • If for a desktop we set the requirements to be able to zoom to 500% of default, then a 16px font becomes 80px, which accommodates 20/100.
  • above the 16px text, we have the 36px headline. If we zoom to make it 500% we end up with a 180px headline which is not only much larger than it needs to be, it's so big readability starts to suffer from being too large. Instead we simply want it noticeably larger than the body text which is now at 80px. Zooming 36px 300% brings us to 108px, which is good relative to the 80px body text.
  • But this won't function well on a cell phone in portrait mode, in which case the zoom requirement of 32px (200%) for the body text is more reasonable, accommodating 20/40. And that large headline, once again we'll increase it less, let's say 150%, that still makes it 54px. If we try to zoom the large headline 200% to 72px, the word "HEADLINE" would not even fit on the screen!
  • For an iPad in portrait or a large iPhone in landscape, we could reasonably bring the body text up about 350% to 56px (20/70), and the large headline up 233% to 84px.
  • Actual examples: myndex.com/WEB/TextZoomExample

---

Non-Text (spatial semantic nonsemantic)

• Encompass non-text contrast and design guidelines in a complementary manner.
  • Spatial frequency effects are just as important to non-text as to text.
    • non text typically has a much wider spatial frequency range
    • non text often has very low spatial frequency, so very different contrast requirements, including extending into hue/chroma contrast.
  • Non-text use cases divided into semantic and discernible groups.
    • Intrinsically semantic (icon or pictogram, land map)
    • Contextually semantic (chart lines, pie chart pieces, demographics map, lat/long lines, legend codes)
    • Meta semantic (focus or state, dynamic driving map, animatable potentially in combination with 1 & 2)
    • Discernible non-semantic (border, abstract button shape, map outer edge or legend area, zoom-up enlargement areas)

---

Hue and Chroma (CVD, auto adjust, auto invert)

• Enhanced-Level Color (hue chroma saturation)
  • Guidelines for alternate color modes including
    • Light mode "paper-reading-experience" guidelines
    • Dark mode(s)—dark mode for day, dark mode for night.
    • daltanization modes enhancing limited color vision
    • monochrome mode and minimum luminance mode (for achromats)
    • high contrast and low contrast modes
  • Extension to the main math method that specifically addresses red and blue light issues
    • especially important for emerging WGD HDR technologies.
  • Extension to the main math method adding in multi-way color considerations.

Needed Technology Adds

1. A CSS property to directly set font size by x-height.
   • related properties for setting spacing relative to x-height.
2. Browser zoom for a relative font size instead of percentage.
3. Automated font weight assessment (something I am working on)
4. Creation of an "accessible reference font"
5. Method for use-case flagging for automated testing (using CSS classes maybe?)
6. Media type queries and use profiles for daltonization types, etc.

Not the Kitchen Sink

The list looks long, but this list is more about process, the actual guideline(s) should have much of this "hidden" and simplifed for ease of use by designers and testers.

---

FOOTNOTES
_{1) Ideally a custom primary reference font is created, with variable weight for at least 300 thru 700, and including 100,200,800,900 at least as individual weights. Primary reference to have a 0.5 x-height ratio, and aspect, letter and line spacing to be consistent with best practices for body text.
2) Appropriate use-case definitions is the appropriate design-friendly way to deal with what WCAG2 called "three way contrast". Not only does WCAG 2 contrast fail for not actually being 3-way, it is trying to solve design use-case definitions without any consideration of use cases.}

_{Copyright © 2021 to 2023 by Somers & MTI. All Rights Reserved.}