Improve the color contrast for structural interface components

Created on 29 February 2024, about 1 year ago
Updated 14 March 2024, about 1 year ago

Problem/Motivation

This is a tricky one. I've discussed the following problem several times with @mgifford. There are already issues for improving the non-text contrast for various user interface components in Core in the context of WCAG2.2 SC 1.4.11:

All those examples are about buttons or button like components the user is able to directly interact with by clicking. All those cases fall directly under SC1.4.11. But there is another related group of structural interface components that are not covered by this or any other success criterion. The color that is used for the background of certain regions/areas as well as certain boundaries/borders is causing a lack of visual structure for many pages in the admin ui. On those pages most of the visible visual structure is provided mainly by the proximity of the micro copy and how it is laid out. Most of the backgrounds and boundaries are more or less invisible or at least require a noteworthy cognitive effort and focus comprehending and interpreting the page structure at hand for someone with visual impairments. A few examples (*Disclaimer: Many of the component overlap in the three screenshot, I've only referenced a component in this summary as well as the screenshots the first time it appears)

A) The content on /admin/content

Structuring interface components affected:

  1. The header (#F3F4F9) against the main content area (#FFFFFF) results in a color contrast of 1.1:1
  2. The fine grey line for the secondary tabs (#D3D4D9) against the white background (#FFFFFF) results in a color contrast of 1.5:1 with a width of 1px.
  3. The outline of the filter field set (#DEDFE4) against a white background (#FFFFFF) results in a color contrast of 1.3:1.
  4. The table header (#F3F4F9) against the white background (#FFFFFF) results in a contrast of 1.1:1
  5. The separating lines between the listed nodes (#D3D4D9) against the white background (#FFFFFF) which results in a color contrast of 1.5:1

B) The content on /admin/appearance

Structuring interface components affected:

  1. The outline of a theme card (rgba(212,212,218,0.8)) against the white background (#FFFFFF) leads to a color contrast of 1.4:1
  2. The color divider (rgba(142,146,156,0.5)) against the white background (#FFFFFF) results in a color contrast of 1.7:1
  3. The outline for the administration theme field set (#DEDFE4) (not visible in the screenshot) against the white background (#FFFFFF) results in a color contrast of 1.3:1

C) The content on /admin/content with https://www.drupal.org/project/navigation โ†’ installed:

Structuring interface components affected:
In addition to the color contrasts listed in example A for the content overview page there is the separating line (#DEDFE4) between the vertical toolbar (#FFFFFF) and the main content area (#FFFFFF) with a color contrast of 1.3:1 in both directions. The separating line (#DEDFE4) against the header background-color (#F3F4F9) has a color contrast of 1.2:1.

In case you are in bright sunlight or you have visual impairments most or all of the listed elements in example A to C are close to invisible or it requires a certain amount of energy to orient and process the available information. I have visual impairments myself, although I am able to see everything, I have to focus and concentrate constantly and this steady effort takes its toll.

By adding the new navigation module into the mix as illustrated in example C there is an additional aspect which has a negative impact on readability. With the current admin toolbar you have the ability to choose between an horizontal and vertical version. The horizontal toolbar variant was always my preferred choice. But until a few weeks ago I was unable to articulate the reasoning behind that choice.

Horizontal admin_toolbar:

  • The horizontal main admin toolbar (#0f0f0f) against the secondary horizontal toolbar (#FFFFFF) underneath has a color contrast of 19.2:1
  • The secondary horizontal toolbar (#FFFFFF) against the 1 pixel solid separation line (#AAAAAA) has color contrast of 2.3:1, but in addition to that 1 px line there is also a 3 px drop shadow that supports the visual separation.
  • The solid 1px separation line (#AAAAAA) against the header (#F3F4F9) has a contrast of 2.1:1. Again through the additional drop shadow width it is at least easier to distinguish the admin toolbar from the header even though the 3:1 color contrast isn't reached.

Vertical admin_toolbar:

  • The horizontal main admin toolbar (#0f0f0f) against the header (#F3F4F9) has a contrast of 17.5:1.
  • The vertical sidebar has menu items (#FFFFFF) against the vertical solid 1px separation line (#AAAAAA) has a contrast of 2.3:1 and the active menu item and the vertical toolbars background in general is #F5F5F5 against vertical solid 1px separation line (#AAAAAA) that results in a contrast of 2.1:1.
  • The vertical solid 1px separation line (#AAAAAA) against the header (#F3F4F9) has a contrast of 2.1:1.
  • The vertical solid 1px separation line (#AAAAAA) against the main content area (#FFFFFF) has a contrast of 2.3:1.
  • Through the additional drop shadow width it is again at least easier to distinguish the admin toolbar from the header and main content area even though the 3:1 color contrast aren't reached.

If you are trying now to read and process the content on a site using the navigation module instead of the admin_toolbar, in my case I am reading/scanning in the LTR reading direction, the content of the main content area is scanned most of the time either with the F-Shape, Layercake, Exhaustive Review, and in part the Zig Zag gazing pattern (for the gaze patterns see https://www.nngroup.com/articles/how-people-read-online/ and https://www.nngroup.com/reports/how-people-read-web-eyetracking-evidence/). With in particular the first three patterns you always start scanning from the very left of the main content area. But with no clear visual separation and distinct border between the vertical navigation and the main content area the starting point for scanning is imprecise. That starting point has to be reevaluated and in case readjust for every new line. If you take for example the sidebar in Slack, where the sidebar and the main content area have a clear visual distinction it is easy for the eye keeping track and it requires way less energy and effort. The eyes have some sort of guardrails and stabilizer that keep them on track.

And talking of scanning pattern having a higher color contrast increases the visual affordance. Visually salient components would be easier scannable with the Spotted pattern where you scan for visually salient components and words of interest.

Steps to reproduce

Proposed resolution

  1. The topic of the header I've brought to the a11y office hours before. Aside the aforementioned problem of color contrast there is also the fact that the user is required to actually read the whole h1, the breadcrumb as well as, if available, the active primary tab to figure out the current context of a page. Reading is actually only available way to determine the current context. The suggestion was to provide additional cues aside the requirement to read. Suggested options were adding an icon for groups of pages like content types, use different kind of background colors and/or add some sort texture. Enabling the user understanding the current general context of a page with the glimpse of an eye so it is only necessary to quickly scan the front-loaded h1 heading (referring to the proposal over there #2514218-101: [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity โ†’ ). Adding different colors to the header would also help improving the low color contrast issues described in example A to C.
  2. The background colors for section headers, table headers, as well as the colors of separation lines and field set and/or theme card outlines might "simply" be increased. That would add more structure to the pages using those components and people could easier orient on a page. It might also be beneficial for information foraging in the context of the Spotted gaze pattern.
  3. In the context of the vertical navigation one approach might be to make it stand out more clearly from the main content area. One example I've mentioned before was from Slack, their sidebar clearly stands out from the chat area. That way it reduces the cognitive load finding the starting point in every line.

I am not sure how to proceed. At the moment this is an attempt to articulate an overview of the whole problem space. One option might be now to provide some sort of higher contrast mode for Claro and add that option in the context of โœจ Add a section to the user profile to store accessibility preferences Active but I think having a more clear visual structure supporting the clear typographical structure Claro already has would be beneficial for everyone and would improve the overall readability further. Therefore it might make sense in case there is some sort of consensus and people see the potential value to change this issue into a meta issue and then create child issues accordingly.

I'll add the issue as a component for Claro and file it as task, it might be also considered as a feature request.

Remaining tasks

User interface changes

API changes

Data model changes

๐Ÿ“Œ Task
Status

Active

Version

11.0 ๐Ÿ”ฅ

Component
Claroย  โ†’

Last updated 2 days ago

Created by

๐Ÿ‡ฉ๐Ÿ‡ชGermany rkoller Nรผrnberg, Germany

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

Sign in to follow issues

Comments & Activities

  • Issue created by @rkoller
  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany rkoller Nรผrnberg, Germany
  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany rkoller Nรผrnberg, Germany
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada mgifford Ottawa, Ontario

    Thanks for posting this @rkoller. It is clear you've put a lot of work into this and giving it a lot of careful consideration. I wanted to emphasize that not all accessibility errors are covered by WCAG SC. Cognitive is going to be covered much better in WCAG 3.0 but it is likely years away before this becomes a W3C Recommendation. That doesn't mean we can wait to address these issues.

    I do think that it would be great to do more usability studies with our authors and admin. Would be interesting to do A/B testing with different ways of organizing and separating the content.

    This also may be a space to explore the use of prefers-contrast to allow more individual choice.

    It would be interesting to see if there are ways that design folks could address some of these concerns in ways that me (as a non-designer) can't necessarily anticipate.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States charlesj

    It is important to avoid the trap of using color as the sole differentiator between states of components. Color differences alone (regardless of contrast values) should never be relied upon in any UI. (Even traffic signals have color as well as positional attributes.)
    The "sliding squib" capsules that replace traditional checkboxes are particuarly problematic. If the color differences are not readily discernable (as in many cases), there is no other way to determine the state of the setting. (Traditional check-boxes never had this issue, obviously.)

    • Not everyone sees color the same way as you
    • Not all monitors are color-calibrated the same way as yours
    • A growing majority of customers use cellphones, with screens the size of a baseball card. Color differences are even more difficult to detect on these small screens.
    • Can screen readers (and other technologies available to vision-impaired customers) reliably interpret the state of color-only widgets?

    I'm not a "visual design" person, but I am moderatley color-blind (like many, many others) and have always struggled with interfaces that rely on one designers perception of color.

Production build 0.71.5 2024