Replies: 1 comment
-
Hi @jonolave Sorry for the delay in response. At the moment, the non-text guidance divides into two basic use cases, that of semantic/primary data, and that of supporting or ancillary graphics. This could be expanded, as presented in Inactive and Semi-Suppressed Components. Draft line thickness vs Lc values:Semantic"Semantic" refers to user interface components that have a literal or other inherent meaning that needs to be perceived, such as a 🏠 for home, or an 📨 for email (Intrinsically semantic), or abstract but nevertheless informational elements, such as a hamburger menu ☰ or a piece in a pie chart (Contextually semantic). Non-SemanticThe "non-semantic" refers to elements such as dividers, and elements that are not strictly part of understanding the information (discernible non-semantic), and this may be where "meta semantic" lands as meta-states of semantic. The next question is "divisional" meaning lines that are not strictly needed for understanding, and should arguably be relaxed/subdued. For this case, under consideration, is relaxing this chart by Lc15. That would put a 1px line at Lc60. The problem with 1px lines is, depending on how they are rasterized to the screen, can lose as much as Lc 30 in contrast, due to blending/antialiasing effects. This is less a problem on retina displays, but is certainly an issue on 72ppi displays. Your comments are welcome. Relation to WCAG 2There is no real relation to WCAG2 here at all. The non-text in WCAG2 has no consideration of spatial characteristics, which are the primary drivers of contrast. APCA Guidelines, and the APC Readability Criterion are more robust and perceptually accurate than WCAG 2. APC-RC is also much more focused on having a good visual hierarchy, which requires flexibility in contrasts. Because APCA is perceptually uniform, i.e. accurate over the entire visual range, we can create effective guidelines at a variety of contrast values, which WCAG 2 does not/cannot. APCA demands higher contrast for thinner elements, and in order for this to work, contrast is appropriately relaxed for thicker elements, in accordance to human perception. Keep in mind that WCAG 2 is not based on the science of visual perception nor readability research. It was never peer reviewed nor empirically tested, and in fact was objected to by stakeholders like IBM back in 2007, but was put into the guidelines regardless of the problems it was creating. Lc 60 vs...Yes, Bridge PCA Lc 60 is backwards compatible with WCAG 2's 3:1. But as I was just alluding to, 3:1 in WCAG 2 is not really meaningful. That value was pulled from an obsolete 1988 standard for monochrome (green and black) CRTs. APC-RC exceed what WCAG2 specifies, though due to the "blunt force" that exists in WCAG2 there can be cases where WCAG2 may incorrectly indicate more contrast is needed, despite falling short in areas where it is actually important (like in dark mode). |
Beta Was this translation helpful? Give feedback.
-
I am part of a team building a design system for data visualisation, and we want to use APCA as a basis for measuring contrast. I have some questions about requirements and best practice for non-text contrast.
The APCA non-text minimums
In order to make a colour palette for data visualisation, we are using this table that we found in the APCA Use Cases and Conformance Research discussion:
Following this, lines of 2px width in a line chart need 60 Lc, while larger areas such as bars in a bar chart might do with 30 Lc.
PS: I made a simple contrast checker for non-text based on the chart above, since all contrast checkers I have seen only deal with text.
Is it only about size?
I wonder if the contrast requirements should be the same for all kinds of graphical elements, just based on px size. For example, in the discussion mentioned above a distinction is made between Intrinsically semantic, Contextually semantic, Meta semantic, and Discernible non-semantic non-text content. But as far as I can see this doesn't translate into different contrast requirements.
A concrete challenge I find with dataviz colour contrast is this: when increasing the contrast of lines in a line chart with multiple colours, it becomes harder to differentiate between the colours. There seems to be a tradeoff between increasing the contrast against the background and making it easy to distinguish between the colours in the chart. And yes, I know that using a lot of different colours in charts can and should often be avoided, but sometimes it is useful.
Also, in dataviz there is sometimes a need to distinguish between the data in focus and contextual data. See for example this line chart from a NYT article:
This might not be the best example, as the gray lines have VERY low contrast, but I think it shows the point: sometimes there is a need to differentiate between "primary information" and "reference information". This might be hard to do, especially with lines, if the reference information needs the same contrast as the primary information. One implication might of course be that we can not use this technique in dataviz.
Another need in dataviz can be to add gridlines. Arguably, these are often not strictly necessary to read the content (especially in digital media where the user can interact with lines and points to get the actual data points). If grid lines have the same contrast as the data itself, it can become hard to see the actual data itself, and result in a very busy visualization.
Basically, I wonder if there is a need to have different contrast requirements for primary non-text information and supporting / contextual non-text information.
Relation to WCAG 2
In the discussion mentioned above I also read:
In WCAG 2, the contrast requirement for graphical content such as a line in a line chart or a border around an input field is 3:1. Following Bridge-PCA, it looks like I can swap this with Lc 60 for APCA.
However, following the non-text contrast table above, if the line around my input field is 1 px, that means a contrast of 90 Lc. So what would be the requirement in that case?
My apologies if these questions have been answered somewhere else, in that case I was not able to find the answers.
Beta Was this translation helpful? Give feedback.
All reactions