Category names in APCA contrast calculator

[detlevhfischer]

I was exploring the APCA contrast calculator today and would like to suggest to provide more context - or explanations - to the USAGE categories used. Here are my comments which reflect my difficulties in understanding, from the category with the lowest contrast to the one with the highest contrast.

1. Non-text only: Does this mean contrast would be OK for Icons? Should this not be something like: "Use never ever if you want to convey information"?
2. Spot and not text: I am not aware of "spot" - what is it? It would be good to define or replace this term and associated OK usage.
3. Large and "soft" text: Reading 'soft', I think of fuzzy or blurred text but this may not be the intended meaning? Again, it would be good to define or replace this term. The notion of 'large' is difficult to grasp given the tool context showing dynamic output of the permissable font sizes across font weight category.
4. Fluent text: Again, I am not aware of the term, I would personally think of text that reflows, but how is that different from body text?
5. Body Text: I thought I understand that, but I am getting confused when I see that there is another category, Body text AAA. .
6. Body Text AAA: No one knows if the WCAG 3 will retain the A/AA/AAA levels, so as the new approach does not fall into these categories (at least not in an obvious way) it is unclear what "Body Text AAA" means. As contrast here is stronger than the unqualified category 'body text', is the implication that "the stronger the better"? Just wondering because parts in the LV community seem to have issues with contrast that is (perceived as) too strong.

Adding something like a (?) option to the USAGE heading opening a category legend may address the questions above.

Another note: I cannot see a means to pick another font (or type of font) to be used the tool's renderings of outputs. Given the significant differences in legibility this would help in making visual assessments (and probably also change the outcome regarding permissible font sizes per foreground/background pair). I guess that is still to be added?

Finally, being able to activate one of the sample text regions to open in a larger window would be helpful in a visual assessment of color/background choices anf the result.

[Myndex]

Hi Detlev @detlevhfischer

Thank you very much for your questions and comments, and sorry for the delay, for some reason I am not getting notifications of discussions. Responses below:

I was exploring the APCA contrast calculator today and would like to suggest to provide more context - or explanations - to the USAGE categories used.....

Understood, and my apologies for documentation gaps. There is a lot going on all at once, and documentation organization is a hefty never-ending project.

The indicator on the left of the calculator is explained in part in documentation under the twisty on the page labeled "APCA Guidelines: Bronze Level." But also, it is intended to indicate the general use case level for the given contrast Lc value.

For more on use cases and related information, please see the thread of draft materials, APCA Use Cases and Conformance which also includes a glossary.

1. Non-text only: Does this mean contrast would be OK for Icons? Should this not be something like: "Use never ever if you want to convey information"?

The non text between Lc15 - Lc30 is for non-semantic non text, such as dividers, outlines, disabled controls, things that should be discernible, but that do not have an intrinsic semantic meaning.

2. Spot and not text: I am not aware of "spot" - what is it? It would be good to define or replace this term and associated OK usage.

The term spot text comes from the research of Lovie-Kitchin et alia, on whom the APCA guidelines are based.

3. Large and "soft" text: Reading 'soft', I think of fuzzy or blurred text but this may not be the intended meaning? Again, it would be good to define or replace this term. The notion of 'large' is difficult to grasp given the tool context showing dynamic output of the permissable font sizes across font weight category.

"Soft" is in fact on its way to being replaced by "sub-fluent" This is test that is secondary content, where full speed fluent readability is not required (and often not possible) with particular application in dataviz and integrated graphics.

4. Fluent text: Again, I am not aware of the term, I would personally think of text that reflows, but how is that different from body text?

Another readability term, it means readability at full comprehension at a normal - mid speed, with critical levels just slightly relaxed from fluent body text.

5. Body Text: I thought I understand that, but I am getting confused when I see that there is another category, Body text AAA.

Body Text is defined as a block of 2 ½ lines or more, where those lines are baseline spaced less than three times the x-height, use a font that is less than 36px (~ 18px x-height), and not characterized as a blockquote (blockquotes fall under fluent or in some cases sub-fluent). This also assumes and specifies the majority of the text is a weight less than 700 and not italic, except for specific emphasis, that full lines in columns are no more than 80 characters, nor less that 35 characters, with 50-60 being ideal, etc.

6. Body Text AAA: No one knows if the WCAG 3 will retain the A/AA/AAA levels, ....) it is unclear what "Body Text AAA" means. As contrast here is stronger than the unqualified category 'body text', is the implication that "the stronger the better"? Just wondering because parts in the LV community seem to have issues with contrast that is (perceived as) too strong.

It just means body text enhanced, which is hard to fit, but I see the confusion, and I just removed it.

The new blurbs are:

• SMALL BODY TEXT ONLY
• BODY TEXT OKAY
• FLUENT TEXT OKAY
• LARGE & SUB- FLUENT TEXT
• SPOT & NON TEXT ONLY
• 🚫 NO TEXT USAGE
• INVISIBLE

MAX Contrast

ALSO Lc 90 is very likely going to be the "maximum contrast" level.

But on this, when the comment or thought is "too much contrast" it almost always reduces to excess luminance, i.e. too bright. This has been an area of active research, and part of a project called "The Paper Reading Experience".

Here is a very simple example:

Adding something like a (?) option to the USAGE heading opening a category legend may address the questions above.

That's a good idea. On the subject of documentation, it has become unwieldy due to the depth of the subject matter. So I have two catalogs for it.

The SHORT is a simple linktree. At the top it starts with the basics, and dives deeper on later links.

The more COMPLETE is this catalog of resources, articles, and links.

Alt Fonts

Another note: I cannot see a means to pick another font (or type of font) to be used the tool's renderings of outputs. Given the significant differences in legibility this would help in making visual assessments (and probably also change the outcome regarding permissible font sizes per foreground/background pair). I guess that is still to be added?

At the moment: guidelines are based around the concept of a reference font (such as the one seen in the tool) any other font should be compared to the reference, and size/weight adjusted accordingly. The draft procedure is in this post: #28 (comment)

That said, font matching to reference is probably going to be a "Gold Level" conformance item, as it cannot be automated yet.

Finally, being able to activate one of the sample text regions to open in a larger window would be helpful in a visual assessment of color/background choices anf the result.

I will add that to the tool feature request list, just as an FYI this APCA tool is designed to be as simple as possible, as some were complaining it was "too complicated"

The larger (and more complicated) SAPC research tool has more going on in terms of font samples, etc. If can be seen at https://www.myndex.com/SAPC/

I hope these answered your questions but please follow up if you have more.

Thank you for reading,

Andy

[sully-justsully]

@Myndex Hello! This is Sully from WillowTree. I've been mulling on the APCA categories and also had a question about the concept of '2.5 lines or more'.

1. If there's a block of text on mobile that is 3 lines but on desktop that same block of text is only 1 line, does that mean the designer needs to account for that criteria change?

2. Is there a possibility of making the category titles closer to design/dev speak?

   • Sub-fluent Text Min => Placeholder, Disabled, & Symbols
   • Large Text => Headlines & Iconography
   • Fluent Text => Large Body Text
   • Fluent / Body Text => Body Text Approved
   • Preferred Body Text = Body Text Preferred

[Myndex]

Hey Sully @sully-justsully

1) Block the column by a line (so said Maginot)

So, one of the specifications that needs to be filled when writing a guideline, is it needs to be "testable" in an objective way that does not require subjective consideration. That was the genesis of the 2.5 lines rule, but I am increasingly not happy with that as the defining characteristic.

Really, body text is large blocks or columns of text, meaning paragraphs. But not all text in a column of text is necessarily body text. For instance, interspersed headings are themselves not body text, just fluent text. Then what about bulleted lists? and block-quotes?

The reason body text has its own specification is that having text in a block results in an increase in spatial frequency due to text being closer together vertically, with most text being surrounded on all sides.

Higher spatial frequency means lower contrast sensitivity.

Spatial frequency can be lowered, therefore contrast improved, by increasing vertical line spacing, or increasing the weight of the font, etc.

Body text needs greater leading, while a headline needs less leading, even if the headline is multiple lines.

Tangent down a dark alley

As of right now, the working draft of the APCA Readability Criterion does not define line spacing per se. And one of the problems with specifying any such layout metrics is the unpleasant fact that every font family is different and not at all standard as far as how the metrics actually render for a given CSS value. Or put another way, CSS values for font-size:, font-weight:, line-height:, `letter-spacing:' are completely inconsistent when rasterized because those values rely on the font file's internal values, which themselves are inconsistent with no standardization.

Here's a page of examples, focused on the need for CSS to allow setting font size relative to the x-height: xheightExample

For line-height: we can get a more consistent result by relating it to x-height, by using the ex length, but even that is not suitable for a consistent guideline, because the needed line height is also related to font weight, font size, use-case... and I haven't even brought up contrast or adapting luminance or...

In essence, it takes a minimum of 8 or 9 dimensions to define readability characteristics. Hint: that probably has to be a task for AI, not a list of abstracted individual metrics.

Back to the point

So the question to answer, what is an objective, testable way to define what is and is not body text? I agree the 2.5 line thing has unintended results in some cases. But also, test in the column, like a larger bolder heading text, is itself not part of the "body" of text as far as perception is concerned.

2) A Gory Cat

I agree that things can be made more "plain language", and that's a principal goal at present.

The categories of "best fluent, fluent, spot, etc" come straight from the Whittaker/Lovi-Kitchin/Ian Bailey readability research. They defined the "critical" acuity size and "critical" contrasts for a number of levels of reading speed and comprehension.

Note that the ratios shown below are for size per acuity, not contrast.

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 Fluent	3:1 to 8:1 (0.5 to 0.9 log units or 5–9 lines*)

(Lines per the Bailey/Lovi-Kitchin log eye chart)

More on levels & categories to the minutiae in discussion #39 including charts relating to critical size etc.

That Said

When the Visual Contrast subgroup reconvenes, this is certainly something to discuss. I've been resistant to such changes during development, just to maintain the connection to the underlying science.

To adopt other nomenclature for use cases, ideally each would be described with a single word, descriptive of purpose. A group I've been considering:

Body, Content, Non-content, Scrap

Body, this is main-content, as described above, columns of text.

Content, which is the text and non-text that is "part of what is intended for the reader's main focus of attention" or in other words, the reason they are on the page.

Non-content, which is all other text/non-text that is not the "reason" someone is on the page, but should be readable nevertheless. This includes the footer material, secondary navigation, and text that is not primary content that should be less contrast to allow the visual hierarchy to draw focus to the main content.

Scrap, this is junk like copyright bugs, the word "advertisement" next to an ad container, disabled text, placeholder text that is NOT a label.

Basically:

Body and Content elements have the highest contrast, and best readability, as this is the primary purpose and focus of the visual hierarchy.

Non-content is most of everything else, relaxed thresholds to allow for a clear visual hierarchy.

Scrap is material that literally does not need to be read, but that should be readable if the user stares directly at it, but otherwise is intended to be non-intrusive.

And I am not saying these are the right set of descriptors either; but I do think each should be a word, easy to remember, descriptive of purpose -- this may be a good thing for a survey study.

UNSETTLED: Do we say that captions for an image are content or non-content? Or is there an additional descriptor for a more granular definition? What is the minimum number of useful use-case levels? At this exact moment in time, I'm thinking:

• Text Use Cases
  • Body content (columns)
  • Primary content (not body, headings, main nav)
  • Secondary content (image captions, asides, tooltips)
  • Non-content (footer, credits, corporate logos)
  • Scrap (copyright bug, ad label, disabled text, non-labeling placeholder)

Is secondary content and non-content really the same as far as "user need", meaning the guideline thresholds? If so they should be combined.

• Non-text Use Cases
  • Semantic (pictographs, icons representing real objects i.e. house, gear, envelope)
  • Navigational (three line "hamburger" icon, arrow, buttons not containing text)
  • Dataviz (pie pieces, chart data lines, data bars, flow chart steps)
  • Divisional (form-field borders, chart grid, separators, buttons containing text)

Is Navigational and _Dataviz _ really the same as far as "user need", meaning the guideline thresholds? If so, they should be combined.

On Visual Hierarchies

A clear visual hierarchy is part of accessibility too. Everything should NOT be at the same contrast, contrasts should be modulated throughout the design for the appropriate hierarchy. If everything were at the same high contrast, it would lead to a cluttered design that was difficult to visually navigate.

Clear visual presentation is a key part of accessibility, especially for coga which is all too often missed.

TL;DR

Questions posed:

1. Body is columns or blocks of text, but what is a testable definition?
2. What is a set of single word descriptors for text use cases? And does non-text use the same, or different set of descriptors?

[cyrezdev]

As usual, big interesting answers by @MyIndex 👍

So, thank you for all your investment in making the web more accessible!

Questions posed:

1. Body is columns or blocks of text, but what is a testable definition?
2. What is a set of single word descriptors for text use cases? And does non-text use the same, or different set of descriptors?

1. For HTML semantics, body is all the content of a web page.
   <main> is maybe more close to what fluent-text is (currently body-text, fluent-text, large-fluent-text...).
   So, is it right to use "body" in the use case of text rendering on a web page?
   Is column speak better by itself?

2. Maybe the way is to be close to the HTML5 semantics? (<header> <main> <footer> <nav> <aside> ...)

That's just ideas... Naming is really a difficult task!

[Myndex]

Hi @cyrezdev

We have not yet set a relationship between use cases and HTML semantic markup, other than mentioning that <footer> is sub-fluent.

“body text” is aimed solely at columns or blocks to of text, and nothing else. The problem we have is how to define in a way that is “testable” ideally with an automated test.

As an example, the text in these paragraphs in this post are body text, but…

This heading is not body text

Even though it is followed by more paragraphs (like this one) which again are body text. This is because body text is specifically about the instance of a block of lines of text. When you are reading blocks like this, issues relating to spacing, weight, and size, and their direct effect on contrast, become critical. In part, because as lines become crowded, effective spatial frequency increases, reducing contrast sensitivity.

If we were to use HTML tags, <article> might be one for body text, but even then as evidenced above, a heading within that would not.

Perhaps we say a <p> when inside certain tags like <article> <section> <aside> or perhaps we say a <p> with a “bodyText” class (or so inherited).

Outside of that, we probably need to consider rules regarding nesting and inheritance (such as a span inside a p or inside an h2 etc).

We also don’t want to set a guideline where just using a <div> negates any requirements like a get-out-of-jail-free card. And using tags as the sole way to define use cases brings this up as a concern.

[cyrezdev]

Hi @Myndex ,

As <body> is the element to open/close a full web page, this is the reason i was wondering about naming body-text.

In HTML, <footer> is inside <body>. The same for all other content HTML elements.

In my mind, what is much "body-text" would be main content text inside the <maln> element.

The problem we have is how to define in a way that is “testable” ideally with an automated test.

Clearly, this is a big challenge!

[Myndex]

Ahhh.... I see how that can cause confusiion, Hmmmm...

So, "body text" is an ages old term we use in the print industry, and was around before computers even existed, much less the WWW. I suppose that's where the WWW came up with the <body> tag...

Perhaps we should just refer to it as "column text" or "text blocks".

Thank you for the comment!

[lloydk]

I was fine with body text.

From Wikipedia which is the first link I get when searching "body text" on google:

The body text or body copy is the text forming the main content of a book, magazine, web page, or any other printed or digital work. This is as a contrast to both additional components such as headings, images, charts, footnotes etc. on each page, and also the pages of front matter that form the introduction to a book.

Column text or text blocks is more ambiguous to me.

[cyrezdev]

As mentionned on Wikipedia:

HTML follows the 'book designer's' meaning of body text.

But also this:

There is no specific HTML element for 'body text' in the typesetting sense. The block elements of <p> and <div> are both used for this, but these elements are used for a great many general markup purposes within HTML and so there is not usually any semantic implication that they always contain 'body'. <p> would generally be favoured over <div>.

Indeed from the start, this term from print could be misunderstood in a modern webpage built with sidebar, navbar, widgets, components, footer...

I didn't think of column text or text block either, but i was maybe wrong thinking of main content (as a primary content or principal content).

From html.spec.whatwg.org, the main element represents the dominant contents of the document.

So, body-textis ok, but maybe we can change its scope?

I explain:

• Set body-text as the default for normal content of the page (not specific to column text, but as a default value like if set to the <body>element.
  Related to the default settings for <body> and its font size, weight, line-height, font family...
• Define use cases when the contrast value can be set differently:
  headings, large text, small text, aside text, footer text, etc...

To sum-up:
Set body-text contrast value for all page content. And you can adjust this contrast value IF and only IF it is in a specific side use case.

The misinterpretation could just be due to the wording and how we define it.
And not by the actual use that results from it.

[seanw]

Hi @Myndex! I was going to start a similar post on this but found this first so just throwing in my fuzzy opinions here. I'm a web developer turned designer to give more context:

• I find designers and developers I work with already have trouble understanding and following the WCAG contrast guidelines (e.g. https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html). It has its own terminology, concepts to learn, the documentation can be long and verbose, there's conditional parts, and it's hard to find a concise summary of the rules to follow. This gets in the way of creating accessible designs because people get overwhelmed and give up.

• I'm finding the APCA documentation a big step up to get my head around compared to WCAG. I've already spent some time reading about color contrast before so I think more casual readers are going to be really overwhelmed.

• Looking at https://git.apcacontrast.com/documentation/APCA_in_a_Nutshell.html for example, I found these phrases very unintuitive: "fluent text" (haven't heard of this phrase before and not guessable to me), "columns of body text" (feels like it doesn't apply to a page that only have a single column of main text), "block text" (overlaps with display: block; layout from CSS for me), "spot readable" (again, not guessable for me). I read above what influenced these terms, but I think it's best to stick to terms that are known by the target audience (designers and devs?) or at least guessable.

• I think suggestions like in Category names in APCA contrast calculator #75 (comment) are in the right direction. I strongly prefer "body text" over "column text" or "text blocks", as it's the phrase I hear most often talking to designers and developers e.g. if we're giving feedback on a web page or mockup, we'll say things like "the body text needs more line-height" (or sometimes "paragraph text", which is more ambiguous but often obvious in context). "body text" also appears on https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html. I don't think there's any confusion here with <body> as that would then be referring to all the text on a web page, so you could tell from the context that this isn't the intended meaning.

• WCAG already uses "Incidental" (from https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html) and "decorative" which I find quite intuitive.

• A concise glossary of terms would really help, which the documentation can link back to whenever a term is used.

• A graphical representation of the glossary would probably help also, like a screenshot of a web page that has headings, body text, icons, copyright notices etc. where each type of text is labelled with its relevant name.

• On https://www.myndex.com/APCA/ and other places, I think instead of writing Bronze levels... Lc 75 • The minimum level for columns of body text... Lc 45 • The minimum for larger, heavier text (36px normal weight or 24px bold) such as headlines, it would be easier to parse if flipped around to e.g. Body text - At least Lc 75... Headlines - At least LC 45. A common question you want an answer to is something like "what contrast do my headings needs to be?" so it's more intuitive to look up this way. (Edit: suggested here as well Another way to organize APCA "General Guidelines" #62 and similarly Reverse lookup table? #27)

Hope that helps!

[Myndex]

I absolutely hate GitHub. I just wrote a complete answer to your post, was about to hiut reply and I'm blind and hit the close button on the window, and GitHub interferes with Safari's built is safety to prevent closing a window with live work and Github does nothgin to sae the work. So annoying.

Here's the short version: I agree and much of what you wrote are great ideas. We are a non profit and open source, so contributions are encouraged.😎

I'll respond again in depth later after my conference calls.