Myndex
commented
3 years ago Hi @melaniephilipp thank you for the comment,
You said:
...for every variation of text and background on a page...
No, only the lowest scoring case. It is functionally not that different than WCAG 2.x, but ultimately is substantially more flexible. The lookup table indicates the minimum of the range, but there are simplified methods to achieve this. And a key important factor is "use case".
To make it simple, here are "key" levels and what they mean. These key APCA levels are the G series undergoing some final evaluations, and are different from the FPWD:
GENERAL GUIDELINES on APCA LEVELS
APCA Key Levels (Series G)
-
90 • Suggested for extremely thin fonts, also 90 is a suggested maximum for very large and bold fonts, and large areas of color.
-
75 • Preferred level for columns of body text. Also, use for any text where readability is important.
-
60 • The minimum level recommended for content text, that is, text you want people to read. "Sort of" like the old 4.5:1 in WCAG2, except perceptually uniform up and down the scale.
-
45 • The minimum level for large text such as big headlines, and semiotic non-text (icons with meaning, but no small or fine details) "Sort of" like the old 3:1 in WCAG2.
-
30 • The absolute minimum for any text, including text for spot reading, place holder text, etc. Large non-text content can be below this however.
-
15 • The absolute minimum for any large non-text that needs to be discernible, but does not convey specific meaning (i.e. no icons), and does not include fine details, such as buttons (not including any text). Designers should treat anything below this level as invisible, as it will not be visible for many users.
Threshold levels
In the very low contrast regions, the values are semi-aligned to clinical type levels (CS), however it is important to note that due to the low resolution of 8 bit monitors, actual clinical use is prohibited for the sRGB version.
So, let's just consider the two, 75 and 60 — these are sort of like the "two" contrasts of WCAG 2.x, one for big text one for small, and we can stop here. For the highest score, maintain the following, (size/weight relative to a qualified reference font like Helvetica):
- Columns of body text, and smaller text: no less than Lc 75, no smaller than 16px, no lighter than 400 weight.
- Other content text (menus, headlines, action items): no less than Lc 60, no smaller than 24px, no lighter than 400 weight.
And done-ish. This is essentially "emulating" the WCAG 2.x conformance, which was developed over 12 years ago, when fonts were "Verdana" and only available in 400 and 700.
However, this is constrictive to the designer. The full new contrast method opens up far wider possibilities for design, rooted in actual vision science, not to mention centuries of classical design for print. In traditional print, small thin light grey text was unthinkable. Yet today it is the core of the very bad design choices permeating the web, and making the web literally unreadable.
And you do not have to fully test all text on the page, just the lowest contrast use case(s) to find the score.
WCAG 2.x requires that all text on a page meet the WCAG 2.x standard, which in some cases is more than enough, and in other cases is woefully inadequate. WCAG 2.x is no longer relevant for today's webcontent, as it was designed around two font weights, and web type fonts that were designed for display use such as Verdana.
Adding Flexibility while Maintaining Readability
If you want to allow designer to use a thin font, 200 or 300 weight, then you can not use such a simplistic approach as WCAG 2.x does. WCAG 3.0 and the APCA does not mandate brute-forced values for cases like non-text, and non-content text (like copyrights or by lines). Instead, key content text must be at the appropriate level for fluent readability. Things like copyright notices can be at the level for "spot reading" which is substantially relaxed.
WCAG 2.x did not define a minimum size, which has resulted in some very bad content designs. WCAG 3.0 does, but does so based on use case, which vastly improves design flexibility.
It is nearly trivial for an automated tool to be created that automatically tests an entire page and all text therein to meet the calculated minimum values, and there are some in the works right now.
But again, for the manual assessment, it is based around the lowest contrast sample as presently stated.
I hope this answers your question, and please feel free to followup.
Thank you,
Andy
Andrew Somers W3 AGWG Invited Expert Myndex Color Science Researcher Inventor of SAPC & APCA Contrast
lauracarlson
ChrisLoiselle
jspellman
Referencing Github issue #272 : Could the Color on the Web Community Group be of help in facilitating a 3rd party review and validation of the research and resulting model?
Referencing Method “Font characteristics contrast”: The method requires assessing a page by applying a lookup table approach that depends on font face, size, and weight (and maybe the use case), for every variation of text and background on a page. (https://www.myndex.com/APCA/). The current state of tools would make this a high manual burden. If tools do not materialize to perform this assessment through automation, this method will be an undue manual burden for assessors.