Requirements for non-text contrast

[jonolave]

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:

To use the APCA tool for minimum Bridge-PCA conformance (backwards compatible for WCAG_2): (..) Lc 60 replaces WCAG_2 3:1

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.

[Myndex]

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-Semantic

The "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 2

There 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).

[jonolave]

Hi @Myndex

Thank you for your reply! And this time it is my turn to apologize for answering so late.

I had not seen that distinction and those values for semantic vs non-semantic. It makes a lot of sense to make that differentiation! And I believe that expanding to more categories could be a good idea, even though there is always a risk of complicating things too much.

When it comes to the Lc values I am a bit conflicted. I do see that there needs to be a certain amount of contrast for the graphics to be perceived. At the same time, the higher contrast there is for the most subtle graphics (e.g. non-semantic), the less contrast there will be between the subtle and the primary graphics.

Consider a simple line chart with gray 1.5 px gridlines, and a 3 px blue data line:

Since gridlines are not strictly necessary to read the graph, we could consider them to be non-semantic. Following the Lc requirements, the gridlines need 60 Lc against the background. As a result, the contrast between the primary data (the blue line) and the gridlines becomes very small: only 8 Lc. It becomes hard to differentiate between them.

Arguably, the gridlines can be considered to be semantic, as they are not pure decoration and represent data points for reference. In that case, they would need 75 Lc against the background, and the grid lines would have to be even darker than the data line. Now, the contrast between the data line and grid lines becomes 0 Lc.

Chart junk?

Edward Tufte addresses specifically the need for muted gridlines, and writes:

One of the more sedate graphical elements, the grid should usually be muted or completely suppressed so that its presence is only implicit–less it compete with the data. Grids are mostly for the initial plotting of data at home or office rather than for putting into print. Dark grid lines are chartjunk. They carry no information, clutter up the graphic, and generate graphic activity unrelated to data information.

If we follow Tufte’s advice, the gridlines would need to be muted, resulting in much less contrast. Another option is to completely get rid of the gridlines.

I would argue that even though the gridlines can be omitted, they can often provide value in visually anchoring the data elements. But having gridlines with high contrast will most likely provide a poorer experience for most readers, including for those who struggle to see low contrast graphics. However, adding subtle gridlines will probably benefit many users without providing a worse reading experience for anyone.

While I follow the intention of visual accessibility that good contrast is better for everyone, I fear that increasing contrast for all visual elements might have the opposite effect: make the resulting visuals worse for everyone, including those with a special need for high contrast.

Just to be clear – I am all for making charts as accessible as possible, and welcome APCA as a highly promising approach. But I wonder if data visualization is quite unique with its need to layer information visually, and put emphasis on some elements over others.

I don’t know if the answer is to use the high contrast gridlines, omit gridlines, allow users to change the colors themselves, change the Lc requirements, or make different requirements for different use cases. But I think it is important to raise these questions, and I am really curious to hear your take on this!

[Myndex]

Hi @jonolave

"...When it comes to the Lc values I am a bit conflicted. I do see that there needs to be a certain amount of contrast .... At the same time, the higher contrast there is for the most subtle graphics (e.g. non-semantic), the less contrast there will be between the subtle and the primary graphics...."

Thank you! This is the exact kind of comments we need to support changes in guidance.

We want to encourage visual hierarchy, and we definitely want designers to be able to separate by contrasts. Here's the thing:

on a nice retina display, a 1px or 1.5px line displays differently than on a traditional display. It it is part of an image it will tend to be scaled, and anti-aliasing will diminish contrast, especially for very thin lines. But there is more here to consider.

"...Arguably, the gridlines can be considered to be semantic, as they are not pure decoration and represent data points for reference...."

I consider gridlines to be in the "container" category. Gridlines are not themselves semantic, but assistive (unless you have different overlapping grid scales, which is bad for other reasons).

The semantic is the symbols/numbers/text on the axis. The "understanding-the-content" element is the chart's blue line. That is understood with or without grid lines. If the element can be removed with no appreciable effect on the understanding, as in this example, then it is an ancillary element.

Under Bronze Simple mode, this is just as easily discarded as under WCAG 2. We are working on the higher level modes to develop salient advice here.

But I see what you mean regarding the 1.5pc grid lines at Lc 60. This came out of the lab, but is not the end all, and still part of the active investigation. At one point we had four levels of size-to-Lc based on four use case segments. We dropped to two for simplicity, but simplicity is not always a virtue.

For instance, I consider an outer container line, and the hash marks are usually more important than grid lines. And grid lines are something that I myself fight with, in terms of "are they helping or causing clutter".

And this is where we run into how a guideline can have a negative effect, if there are not well considered exceptions.

And to mention, part of this was part of an effort to see if we could align with WCAG 2—but it continues to be increasingly clear that the WCAG2 1.4.3 and 1.4.11 in particular have a net negative effect, whereas we are interested in actual accessibility, and exploring how to best implement this while doing no harm.

"...allow users to change the colors themselves, ..."

User personalization is almost always a best practice as an available feature. We have that guidance in the works as well.

Sorry I can't go into greater detail, I have some intense deadlines at the moment.

[jonolave]

Thank you for the quick reply!

I appreciate the encouragement of visual hierarchy. And I share the view that the best results are achieved when grid lines don’t strictly adhere to either semantic or non-semantic contrast requirements.

Including some description of this in the guidelines would be helpful. It’s still a bit unclear to me what the difference is between non-semantic and ancillary elements that do not have to follow the requirements. You mentioned:

"non-semantic" refers to elements such as dividers, and elements that are not strictly part of understanding the information.

And:

If the element can be removed with no appreciable effect on the understanding, as in this example, then it is an ancillary element.

Could a divider be considered ancillary and thus not require non-semantic contrast?

Layers of semantic elements

Moving beyond gridlines, I believe there is more to discuss regarding semantic elements. In data visualization, layering information poses unique challenges for contrast.

Consider this graph from the IPCC Special Report on the impacts of global warming (2018), designed by InfoDesignLab.

This graph, approved by hundreds of international scientists, presents recorded temperature data up until 2017, and 3 possible scenarios for the next 80 years. It is mostly viewed on screens, despite being designed for a written report.

Sample analysis

Zooming into the recorded temperatures reveals multiple information layers. The black pills with the Lc values are my annotations.

The layers are:

1. Observed monthly global mean surface temperatures – gray line, Lc 17 against a white background
2. Estimated anthropogenic warming – subtle orange area, Lc 17 against a white background
3. Estimated anthropogenic warming – orange line in the middle, Lc 47 against the orange area, and Lc 23 against the gray lines (with semi transparent orange).

Regardless of line widths, creating such a multilayered chart while adhering to APCA contrast is challenging.

Alternative approaches

Here are some alternative approaches to making the graph visually accessible:

• Simplify the graph. Removing layers like the observed monthly temperature can increase contrast for remaining elements but may conceal important information (e.g. the variations in the observed temperatures)
• Create multiple graphs. Splitting each layer into separate graphs can enhance visual accessibility but hinders understanding of layer interactions
• Interactive exploration. Allowing users to explore the graph interactively can help, but the default state may still lack sufficient contrast
• Provide alternatives. Offering different ways to access the layered information (separate charts, tables, audio, textual description) helps, but doesn’t solve the visual contrast issues in the graph itself.

Balancing contrast and information layers

Many useful graphs and maps show multiple layers of information simultaneously. Discarding such chart types due to low contrast would mean losing valuable tools for discovering and communicating important patterns and correlations.

While maintaining contrast requirements is crucial, I wonder if accessibility could sometimes be achieved by providing alternative ways to consume information, and include a multilayered chart that doesn’t fulfill all contrast requirements in its default state. I’m curious to hear your take on this.

You mentioned lab experiments. Have these been documented or published? It would be interesting to learn more about the process.

Sorry if I’m bombarding you with questions. I hope this discussion can contribute to the guidelines work.

PS: No rush on answering!

[jonolave]

Hi @Myndex
Hope you are doing well.
I was wondering if you have made any progress on non-text contrast, and/or if you have some input on the questions above.

II will be presenting at a conference on Universal Design in a few weeks, on using APCA for creating a dataviz colour palette. If at all possible, it would be useful to have a bit more clarity on these issues before submitting the final presentation.