Myndex
commented
1 year ago @alastc Hi Alastair, can this thread be marked with the labels
- migration: guidelines
- Subgroup: Visual Contrast
Thank you.
Open Myndex opened 1 year ago
Myndex
commented
1 year ago @alastc Hi Alastair, can this thread be marked with the labels
Thank you.
Color and Contrast Outcomes
(for survey)
Color, as in hue and colorfulness, is distinctly separate from luminance, which is "colorless" spectrally weighted light.
It's convenient to think of luminance as a black & white TV set, and to think of color as just the small amount that's added to that black-and-white signal. Because that's literally how the human vision system processes it as well, and the separate components of luminance and color serve different purposes in our neurology.
NOTE: The fact that contrast sensitivity is dictated by spatial frequency is a matter of peer-reviewed scientific consensus dating back to the 1960s. ⁵
Click for additional background
_**Luminance**_ carries the **high** spatial frequency information such as text, and color (hue) exists in the very **lowest** spatial frequencies. _"...reading speed depends on the spatial frequency and contrast of the text. When text contrast is low, reading speed shows strong spatial-frequency dependence..."_ ⁴ Visual presentation properties such as line spacing affect spatial frequency and therefore directly affect contrast and readability. Currently they are in a different area, but they belong as part of the overall visual contrast/visual hierarchy group. DataViz and nontext are often at low spatial frequencies, and use of color for data coding is related closely to DataViz, but _not particularly related_ to visual contrast for readability. Meanwhile, reading _requires good luminance contrast_, without regard to color as in hue. _(An exception is rejecting pure red paired with black or dark colors, note that APCA essentially does this naturally anyway, as read on black is actually bad for standard vision as well)._As such, color (hue/colorfulness) and DataViz/non-text contrasts fit well together in a group,
And then spatial and luminance tests/parameters fit well together for readability contrast.
Some of the other adds:
Text zoom, Text use-cases, non-text use-cases, text in an SVG, contrast for images of text/logos.
Click for additional background
These were some editorial adds made to the Google doc along with comments. I did not delete any lines from the other areas such as visual presentation, but I did leave comment notes at those in the document. - Text zoom, as text size is a primary factor in visual contrast because of the spatial frequency characteristic of text size, the ability to zoom text and the nature thereof is important. - **Text use-cases** and **non-text use-cases**, as it provides the structure for which elements must have high contrast and which elements can have relaxed contrast which is required for practical design implementation.⁶ - And while images of text does partly belong over with alt text, it **_also_** belongs in visual contrast, as images with text or semantic imagery that is required for understanding content. Also added a line for "text in an SVG" and formatted rich-text for alt text in conjunction with images/SVGs of formatted text or logos.For convenience, here are the tables relating to color and visual contrast from the Google doc as split / combined into these two guidelines:
Guideline: Content does not rely on color alone to convey meaning, uses sufficient contrast.
Scope: Item or View
Expertise Needed:
Guideline: Visually readable content uses ample luminance contrast.
Scope: Item or View
Expertise Needed:
Thank you for reading.
A general reference for a crash-course in color and contrast: The Realities And Myths Of Contrast And Color
Footnotes 1) G.Legge, et alia (Psychophysics of Reading) 2) M.Stone (NIST,Guidelines for Using Color...) 3) L.Arends (NASA,Individual Differences in Color Vision) 4) S. Chung,B.Tjan Spatial-frequency and contrast properties of reading 5) Stevens, 1961; Bartleson and Breneman 1967
6) Click for refs & discussion of text use cases
### Text Use Cases * **FLUENT** *(primary content)* * **High-Fluent Readability** *(Block/Body Text)* * **Defined as:** a block or column of *more than two* continuous lines of content text that uses a readable font with an **x-height** of \~16px or *less ( < 32px)* . * \*\*Fluent Readability (\*\**Primary* content that is *not* body text) * **Defined as:** *up to* two and a half lines of continuous text. * **Large Fluent header/title content** * **Defined as:** fluent subcategory of "large content" such as big, bold headlines, and generally referring to text larger than \~32px. * **SUB FLUENT** *(secondary content)* * Soft Readability, small sub-fluent secondary/ancillary content * **Defined as:** non-primary content with *relaxed* readability needs. * **Spot Readability,** *(sub-fluent* ***"non-content"****)* * **Defined as:** non-content text of an incidental nature. * **Logo or Branding,** **brand related logo, symbol, service mark.** * This category relates to specific colors that are required as part of a brand or logotype. * **Incidental Text in Images** incidental means text in images not critical to the understanding, nor specifically contributing to the content, in other words a photo of a city street, and you can see the text on the signs for the various stores. ### NON Text Use Cases Regarding nontext use cases, one set is: - 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) So another idea for non-text use cases is: Semantic, Symbolic, DataViz, Container SEE: Draft [Use Cases, Conformance, Research, and Glossary](https://github.com/Myndex/SAPC-APCA/discussions/39)7) Click for refs & discussion of characters per line
"80 characters per line" is a somewhat unsupported value pulled out of thin air. The history of 80 characters has much to do about the economics of IBM's equipment back in the day, than it has to do with any actual readability research. In other words, asserting lines should be 80 is pseudoscience. Lines of code can reasonably be much longer and there's a number of arguable reasons to not have line breaks in code. But 80 characters is usually too much for columns of body text, which should be much shorter, and this varies per language and writing system. **_"...The 66-character line (counting both letters and spaces) is widely regarded as ideal...."_** -R.Bringhurst from the authoritative _"The Elements of Typographic Style"_ ### _It could be non-normative and informative._ the best practices recommendation for columns to have an average line length of 50 to 70 characters (for latin-based). Other languages need an expert typographer in that specific language to work on certain international outcomes.8) Click for discussion of body-text justification
### For web content, columns of body-text must be: - left justified for ltr reading languages, (meaning aligned to the left) and - right justified for rtl reading languages, - **Never** full-justified, meaning full lines aligned to both the left and right margins, and - **Never** center justified—Center justified body-text is actually harder to read them full-justified. It's important recognize that full-justification requires the judgment of the eye of a skilled typographer in order to make it work. Web content is responsive and interactive and changes position. Like all automatic adjustment systems it does not benefit from human intervention, and the automated systems for things like text reflow in a browser are not nearly at the level they would need to be to accomplish appropriately set full justification. That said, central justification of body text is even worse for reading, because the beginning of each line is that a different place that makes it very difficult for the eye to scan back to the beginning of the next line. And also, all of this is for body text. These rules do not and should not apply to two or three lines of much larger headline text as an example. On that note, **_the use case for body text is very different from the use case for any other form of text on a page._**9) Click for refs & discussion of line-height
This is from another unsupported SC which originally says something like "must be 1.5 times the line height". This is **practically meaningless in CSS**, because what's important is the distance between glyphs, and for Latin alphabet for instance, that's going to be between lowercase Lines, and the x-height ratio to font-size is vastly different depending on the font family, by as much as ±50% or more. ### _It could be non-normative and informative._ While I revised it for now to be 2.5 times the x-height, i.e. `p{line-height:2.5ex}`, even that is not the whole story. Whether or not increasing line height to a certain degree is helpful is not a matter of scientific consensus, and there are enough variables involved that it's not so cut and dry, and I certainly dependent on the font design font weight and overall size and number of characters per line on average and so forth. This goes for paragraph spacing as well, is there a number of ways to indicate paragraphs including indenting out outdenting, and it is out of scope for a law to say that you must use paragraph spacing as opposed to indenting as an example. These arbitrary values are really notwithstanding, as the reality is much more nuanced. Nevertheless, it is well known though is that the spatial frequency and the effects of crowding are very important readability, but you can't make a blanket statement on how much letter or line spacing needs to be added, as that is a function of every individual font design and **every individual font design is going to need something different.** ### Blanket arbitrary values do not work here Especially not in a guideline that is intended to become law at some point. _Some related references:_ D.Pelli et alia [Crowding and eccentricity determine reading rate](https://pubmed.ncbi.nlm.nih.gov/18217835/) S.Chung et alia [Reading speed does not benefit from increased line spacing in AMD patients](https://pubmed.ncbi.nlm.nih.gov/18772718/) A.Calabrèse et alia [Small effect of interline spacing on maximal reading speed in low-vision patients...](https://pubmed.ncbi.nlm.nih.gov/19834038/)