Category names in APCA contrast calculator #75
Replies: 9 comments 5 replies
-
|
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:
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.
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.
The term spot text comes from the research of Lovie-Kitchin et alia, on whom the APCA guidelines are based.
"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.
Another readability term, it means readability at full comprehension at a normal - mid speed, with critical levels just slightly relaxed from fluent body text.
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.
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:
MAX ContrastALSO 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:
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
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.
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 |
Beta Was this translation helpful? Give feedback.
-
|
@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'.
|
Beta Was this translation helpful? Give feedback.
-
|
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 alleyAs 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 Here's a page of examples, focused on the need for CSS to allow setting font size relative to the x-height: xheightExample For 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 pointSo 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 CatI 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.
(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 SaidWhen 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:
Is secondary content and non-content really the same as far as "user need", meaning the guideline thresholds? If so they should be combined.
Is Navigational and _Dataviz _ really the same as far as "user need", meaning the guideline thresholds? If so, they should be combined. On Visual HierarchiesA 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;DRQuestions posed:
|
Beta Was this translation helpful? Give feedback.
-
|
As usual, big interesting answers by @MyIndex 👍 So, thank you for all your investment in making the web more accessible!
That's just ideas... Naming is really a difficult task! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @cyrezdev We have not yet set a relationship between use cases and HTML semantic markup, other than mentioning that “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 textEven 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, Perhaps we say a 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 |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Myndex , As In HTML, In my mind, what is much "body-text" would be main content text inside the
Clearly, this is a big challenge! |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
I was fine with body text. From Wikipedia which is the first link I get when searching "body text" on google:
Column text or text blocks is more ambiguous to me. |
Beta Was this translation helpful? Give feedback.
-
|
As mentionned on Wikipedia:
But also this:
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, I explain:
To sum-up: The misinterpretation could just be due to the wording and how we define it. |
Beta Was this translation helpful? Give feedback.
-
|
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:
Hope that helps! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Can someone please clarify the logic behind "Small Body Text Only"? I understand that extremely high contrast can increase eye strain and reduce readability, so the need for Lc 90 as a maximum contrast. I just don't understand why it has been limited to small body text only? If anything, I would have thought text above the maximum contrast would exclude small body text as too strenuous on the eyes and it would be limited to larger font sizes that would otherwise be considered more readable - like a bold headline. Why is this not the case? Haven't found anything that speaks specifically to this point. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
I'm no expert but my guess is that it has to do with halation, or the halo effect. On small/thin text, the halation effect would be minimal. But on large/thick text, halation would become a much more significant problem. Again, this is just a thought! |
Beta Was this translation helpful? Give feedback.
-
Where are you seeing that Lc 90 is the maximum for "Small Body Text Only"? For light mode there is no maximum contrast. For dark mode there are some preliminary suggestions for maximum contrast in this discussion |
Beta Was this translation helpful? Give feedback.
-
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.
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.
Beta Was this translation helpful? Give feedback.
All reactions