Replies: 4 comments
|
Hi @angyb The lookup table was an initial experiment, and the "add Lc15" was an attempt to simplify. We are making some changes—among other things, the strict adherence to certain table metrics is for the Silver and Gold levels, not the Bronze level. The current public draft guideline is https://readtech.org/ARC/ and in particular, see the "Bronze Simple Mode". Body text has a higher |
|
@Myndex We're doing a major redesign, and I hope to make our work as future-proof as possible (given that APCA-RC is still in draft). We make an educational product used in public schools and must meet WCAG 2.x AA minimums before a school/district/state will consider purchasing our product. I thought using the Silver lookup table would ensure we are also compliant in the future WCAG 3.x. If I use the Bronze level guidelines, will I likely (hopefully?) be compliant with WCAG 3 minimums? Or should I be looking at the Silver LUT, since we need to meet WCAG 2.x AA minimums? I realize you can't see the future. Your best guess will do. The Bronze guidelines also say: "Lc 30 - The absolute minimum for any text not listed above. This includes placeholder text and disabled element text." This is confusing to me because it also recommends a font size of 36px for non-body text at Lc45. In which case, how big must placeholder text be if it's Lc30? And what about 12px hint text that appears below a field input? Must it be Lc90? That seems excessive for supplementary text. I made this table for myself to better visualize the Bronze level guidance. This seems to suggest that no body text should ever use any contrast lighter that Lc75. Am I interpreting this correctly? (b=body text, nb=non-body text)
|
ComparedWCAG 2 A level does nearly nothing at all for visual contrast or visual accessibility. APC-RC Bronze is "equivalent but better then" WCAG 2's 1.4.3 and 1.4.11 (AA) APC-RC Silver is better than WCAG 2's AAA APC-RC Gold is intended as a best-in-class complete system, though the deeper we research, the more complex it becomes, and is currently exceeding available technology (requires polyfills). WCAG 3, at present, has no actionable guidelines as they relate to visual contrast. Nuances of APC-RCWCAG 2 has no guideline for disabled text. APC-RC does, but not in the lookup tables. The draft discusses this more, for instance regarding text use cases: https://readtech.org/ARC/tests/visual-readability-contrast/?tn=conform This is draft, your thoughts and comments are very welcome. Keep in mind that visual hierarchy is also an important accessibility issue: not everything should be at high contrast. A good visual hierarchy guides the reader through the most important context, and ancillary, secondary, and non-content can and should be at much lower contrasts for this reason. Generally, disabled controls should be about Lc30 less than the non-disabled control, to clearly show the change of focus, for instance. |
|
I last updated my personal tools in 2022. I am refamiliarizing myself with the APCA-W3 standards to make sure I have the most up to date rules, and I am making more detailed lookup tables for each use case, font (sans) serif, font weight, and font size combo. Basically, each combination is 1 row so that there can be no confusion about how to interpret the rules. I can't seem to remember how to interpret the table in the original post of this discussion: APCA Contrast to Font Table - Sorted by Contrast Lc Value. Beta 0.1.7 (G) Revised May 2027, 2022. For example, how do I translate this rule: Back in 2022, I followed the APCA instructions for How to Qualify Font Size and Weight. I used Fira Sans as the reference font so I am pretty sure my main project fonts have font weights and font sizes that are the perfectly aligned with the APCA reference fonts weights and reference x-height ratio of 0.52. I don't think I need to scale the APCA table values before applying the rules to my fonts. My main project fonts are customized Google Fonts so their x-height ratios are 0.52 to 0.54. However, most of my backup fonts like SIL fonts have smaller x-height ratios 0.44 to 0.48. Edited: Oh and one more question. This table was created using sans serif fonts as a reference font. Does the following serif rule still apply? How do I adjust using the Sorted by Contrast Lc Values lookup table for serif fonts? Thanks for all your help. The standards are incredibly helpful. The tricky part is that there are so many rules spread out across multiple sites and pages. I just need a more straightforward set of lookup tables because there are so many rules and exceptions. It is hard to keep translate all of them in my head especially after not reviewing the rules for a long time. I'd be happy to share the spreadsheet lookup table for other people to review and use. |

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
@Myndex
The “+15” for body text for certain font sizes in the lookup table doesn’t make sense to me. If I want to use an 18px font (Helvetica) for body text, I need an Lc of 75 (equivalent to WCAG’s 4.5:1). If, instead, I want to use a larger font, say 24px, I still have to use Lc 75 (rather than Lc60 which is equivalent to WCAG 3:1 for a font this size). 24px is 33% larger than 18px, why do I need to use the same Lc75?
Couldn’t we have a table with more discreet Lc for body text instead of a blanket “add 15”? In my example, 24px at Lc60 appears to be nearly the same luminance as 18px at Lc75 and is equally readable (in my possibly flawed opinion). While 24px at Lc75 appears significantly darker.
Couldn't we have a LUT for body text and another for sub-fluent non-body text? It would add so much clarity to be able to look these up independently based on how they're being used.
Thank you kindly.
All reactions