Confusion with lookup tables #64
Replies: 2 comments 4 replies
-
|
Hi Colin @JustColin
This is a good question, and we are considering a 3D LUT to address this, but in the meantime, let me give you some additional guidance. There was an earlier multi level type LUT displayed at the SAPC development site, but for APCA W3 we have been working on simplification.
Can you show me an example? If it's proprietary, you can email it to me in confidence — there is discussion regarding divisions of use cases, best fluent, fluent, spot, etc etc... Answers
If the use case is "spot" non-content then yes, the amount of derating to be determined, but probably Lc 15 to 20 ish, depending on size and weight. ("spot" covers non-content text such as copyright notices, disabled links or controls, placeholder text, etc). If the use case is fluent content that is not body text, then mostly no, but again it is weight dependent. At issue is the major stroke width, as referenced in a capital I. We are discussing an additional use-case for "soft content" that is a level stronger than spot, but not at the full needs of fluent text, for things like call-outs, legend elements, etc.
Okay, so this gets directly into how fonts are rasterized on a typical (not retina) display. Even with subpixel antialiasing, small thin fonts tend to render at a softened and sometimes lower contrast than the CSS color would imply. This is sometimes caused by improper use of the "-webkit-font-smoothing:" property, or by some rasterizers, or other reasons. Small font sizes and weights where this is likely to be an issue, are set to a minimum Lc value that ends up being close to the value needed for body text, so it is set as "green" for body text. Larger heavier fonts that are not prone to this problem can be at a lower Lc for single line type applications, and still be "fluently readable" .... but if put into a block of body text (which reduces perceived readability contrast) then you need to add Lc 15 for body text. And this is the reason for the split. The small fonts that have high contrast requirements for rasterizing reasons are already at the high level needed for body blocks, but they would be good to have Lc 15 added AS WELL... however, that would also become restrictive for design. Some Foundational BasicsFor dark text on light backgrounds, and the text is 24px or smaller, the text should be Black is ideal for dark text, and really the only time dark text on a light background should be anything other than black is when:
With black text On the subject of a blue link: with the I am not certain where the "grey text" thing came from, but it's not good. I suspect it is a misunderstanding on using "reduced contrast" but reducing contrast for an element with dark text on a light background is best done by darkening the background.
Excellent, I am looking forward to hearing comments. We have a lot of potential options and considerations that are not yet released, waiting to hear from beta testers using the current "most simple" versions. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for getting back! Took a bit of time to get some examples of the sorts of websites I regularly deal with to better illustrate what we deal with.
Can you describe in a bit more detail what the 3D LUT would be? One area I am especially interested in is a LUT for non-text elements. A LUT to determine what is the acceptable contrast for a given line/element thickness would be extremely helpful for creating accessible data visualizations, non-text interactive elements etc.
I do a lot of work with admin interfaces used by networking and security professionals. In those applications, large data tables with links/buttons are extremely common. Due to the nature of how tables scale and the sorts of data we have to display there are limits on what we can do in terms of text sizes. I've spoken with some of our senior designers, played with our UI's a fair amount, and the limits are around 14–16px. Any larger than that and event some pretty tame data tables start breaking at reasonable screen sizes. (Even getting up to 14px won't be easy, as many have spend years doing designs around 10–12px, and changing those habits takes time.) The following examples are just illustrative. Yes, they have many accessibility problems, yes links need to be underlined, colors changed, etc. These examples come from a variety of applications, some of which I don't work on, some which are currently undergoing redesigns, etc. Sharing them not as examples of good accessibility, but the sorts of data tables commonly used for IT admin interfaces:
Some tables will get even more information dense than this, but they should suffice as average examples. Getting plain text in data tables to be upwards of Lc 95 for these tables is pretty easy. However, there is no way to make embedded interactive elements like normal weight links Lc 95 without having a link color that is almost indistinguishable from the plain text color. With the current LUT, we could consider making those links bold, dropping the requirement down to Lc 75. However, I question whether large paragraphs of body text really needs to have the same contrast requirements as a button or link with only one or two words in it. It would be very useful to have "soft content" requirements for these situations with short bits of text (labels, links/buttons in tables, menu bars, etc) where there are multiple design requirements and we can't just have arbitrarily high contrast without losing out on some other element of usability. However, you know more about the science and thus my want to have a discussion with you. 😁 Note: specific color recommendations are not helpful given the sorts of very large scale projects and color systems I advise on. My interest is not in what specific colors will/won't work in specific situations, but understanding the finer details of these color requirements and advocating for the flexibility designers need so they can balance when their requirements conflict.
Could you speak more about this? Links and other short interactive elements aren't always blue, so is the exception you are considering only related to blue elements, or any hue? |
Beta Was this translation helpful? Give feedback.
-
|
Wanted to circle back and see if you had any feedback based on the questions above @Myndex. Especially this:
I get a lot of questions from designers about designs with lines that are 1px thick (occasionally 2px). The general guidelines listed at https://www.myndex.com/APCA/ are okay, but only give the case of 3px lines. Have a LUT for non-text elements like section dividing lines, icons, input borders, etc would be extremely helpful. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @JustColin I've been working on a new iteration of the basic tool, and I've set it up specifically such that I can add in a dynamic non text LUT. The redesigned tool is: https://www.myndex.com/APCA/indexK (temp development link, will expire in a few weeks probably) While it does not show such a defined LUT yet, you can see that that is on the way, with some use case features now implemented. Also, did I ever give you a link to this thread?: It discusses use cases and the direction headed for non text, and has some informative graphics. Lines in the sandSo, with a look at the contrast sensitive graphic on the above link, we can very "roughly" say that 1px needs a near maximum contrast, as in 90 or more. This is very rough, please don't set it in stone anywhere: But context is important... are we talking about a singular 1px or 2px line that has beaning? Or a series of 1px lines that are part of a texture? |
Beta Was this translation helpful? Give feedback.
-
|
It has been a few years since I read through all the APCA guidelines. I am trying to update some of the guidelines in my personal spreadsheet tool. I am essentially defining minimum Lc values rules for each font-size and font-weight combination. Like a master look up table that can accommodate pretty much every useful combination. A few years ago, I think I just made assumptions to fill in the gaps in the font-sizes in the lookup table. I am wondering if I should make those same kind of assumptions with the Beta lookup tables. I also noticed that Lc values for the body text/block text are only available for certain font-size and font-weight combinations. For Non-Body text:
For Body text:
For example: Edit: I had read through #39 but I couldn't find an easy to consume table or list. |
Beta Was this translation helpful? Give feedback.
-
|
The current LUTs are: https://github.com/Myndex/apca-w3/blob/master/data/LUT-GseriesMay28-2022.js That repo and the NPM also have utilities for transversing the LUTs. Linear interpolation is permitted, as is rounding the LC value to the nearest whole number. Keep in mind the LUT was created based on the reference font Helvetica. Other fonts will differ, and there's some guidance on that at the APCA Readability Criterion. |
Beta Was this translation helpful? Give feedback.
-
Howdy,
We've continued trying to incorporate APCA into our internal design guidelines, starting with a project to create a new shared design system across many products (web, desktop, and mobile apps).
One bit of confusion that has come up is that the LUTs current only separates body text from non-body content in a handful of spots:
Some recommendations (such as #31) split contrast requirements completely between different content types completely. That flexibility is great to have, but without a full LUT, it is less useful. This is especially true as we make some very data dense applications that need to use non-body text sizes around 14–16px.
There are a lot of questions I have around this, and feedback for discussions you have open like #45, but I'll start with these questions:
Once we get answers to these I can dig in further with some other things we've found and share some feedback from having a lot of designers look at the current APCA guidelines and LUTs.
Beta Was this translation helpful? Give feedback.
All reactions