The Saga of Accessible Colors – Video and Slides

I recently gave a presentation for Maxability about color contrast. This is a complex topic and could never be fully covered in one hour. I hoped to bring some understanding of why we still have problems with color contrast, understanding why designers may use a color that doesn’t meet color contrast requirements, and strategies to build better products.

Slides

The Saga of Accessible Colors

 

Muwekma Ohlone People

“I want to respectfully acknowledge the Muwekma Ohlone People, who have stewarded this land (San Francisco)  throughout the generations.”

Accessible Color Contrast

What is your reaction?

Color Contrast for Designers

Designers can have a negative reaction to color contrast conversations. Especially when the designer is limited by a company approved set of colors and they don’t have the power to make arbitrary changes. It’s important for accessibility teams to empower designers by emphasizing what they do have power to control, such as naming, accessible text descriptions, focus management, keyboard interaction design, typography, and more. Identify where colors can be improved within the approved color palette. Many times the low-contrast color is a non-standard, perhaps outdated choice. It’s also important to focus color contrast changes within the greater color conversations and include color-blindness, dyslexia, and dark mode/high contrast considerations.

Color Contrast for Developers

Developers don’t have much control over color contrast. It’s important to educate developers about color contrast and give them the power to question designs that promote low-contrast colors. They should have the confidence to go back to the design team for a specification that uses good color contrast.

Color Contrast for PMs

Color contrast is just one of many competing requirements for project managers. While they may be supportive, they are also juggling resources and need to know what their team can control. They may not be able to change the company’s color branding, but they can prioritize issues that are relevant for their screens, such as an incorrect use of light grey where it should be dark grey.

Color Contrast for Users

Your customers need adequate color contrast. They are complaining when designs include low-contrast colors. You may not hear the complements when a site uses adequate colors, becuase it just works. And isn’t that our goal?

4.5:1 Battle Cry

Color contrast requirements are based on a specific ration of foreground text and background color. Standard text needs to have 4.5:1 color contrast. Large text can have 3:1 color contrast. This is not a perfect measurement, but it does provide a solid standard and ensures people with low-vision, cracked phone screens, dirty monitors, and someone checking their emails outside a coffee shop can read their screens without undue stress.

WebAim 1 Million

86.3% of screens had low-contrast text.

Diamond’s State of the Accessibility Report (.pdf), released for Global Accessibilty Awareness Day 2020, highlights 85% of pages have low contrast as determined by automated testing

This was the analysis done by the WebAim 1 million. It’s a horrible number, but is it as bad it sounds? I did an evaluation of Intuit’s home page and several sites listed in the Alexa top 10 to see what was being highlighted as low contrast.

Intuit Home Page.

There are two areas identified as having low contrast. One section has good contrast, but there was an animation as the page loaded. This was identifed as having four issues. Another section was below the fold and had a white heading on a light grey background. As the user scrolls, the light grey background was replaced with a dark image, which provides adequate contrast. The solution, for both of these is to not depend on background images and include an adequate contrast when the image is not present.

Google Home Page

The Google home page has a single "." that is white on a white background. It’s probably used for performance tracking and is not meant to be discovered by the customer. It also includes aria-hidden="true" to remove it from the Accessibility API.

YouTube Home Page

The YouTube home page has a lot of content. But the trademark string at the bottom of the page uses 3.19:1. This is an error, it should be 4.5:1. But it’s a small percentage of the content.

QQ.com

This popular site in China has a lot of color contrast issues. Wave found 81 issues and Axe found 67. There’s a lot of room for improvement, especially with medium blue content on light blue background. But there majority of the issues are above 4.4:1. This is still an error, but not as bad as a page full of 3:1 and below.

Automated Testing Doesn’t Tell The Whole Story

* This is not an excuse to design with inaccessible colors

Goals For Today

  • Understand Overlapping requirements
  • Explore Conflicting User Experiences
  • Learn strategies for moving forward

Color Challenges

Call to Action buttons

Readable vs. Actionable

Intuit uses Orange for primary call to action buttons. The current orange does not provide 4.5:1 color contrat.. Orange gets muddy at 4.5:1

But orange provides visual contrast against blue/black typography.  The orange button creates a clear call to action, which is important for some customers:

The TurboTax team is investigating options to replace the orange button. They’ve added a color theme that switches the orange button for an accessible blue button. But this has some tradeoffs. The blue button matches the page’s colors and doesn’t stand out as the clear call to action. They ran tests, via UserTesting.com to test the actionable nature of the buttons. While the blue buttons are more readable, people with low vision and color-blindness had a slight preferance for the orange buttons.

Warm colors, such as orange, advance on the screen. Whereas cool colors, such as blue recede on the screen. This is one reason why orange call to action buttons have great strength

White vs Black Text on colored backgrounds

The Myths of Color Contrast Accessibility suggested low contrast text, i.e. white on medium blue, is more readable than high contrast text, black on medium blue. This was countered in There is no “Myths of Color Contrast Accessibility” by Geoffrey Crofte. Crofte points out the examples were limited, the blue could have been an accessible color, and the color of the background page impacts the readability of the button text. In short, the original post gave a popular argument for using low-contrast, but this was not sufficient to defend design decisions.

Defending low contrast decisions

Call to action buttons are an example of a low-contrast design decision that could be solved with a different color choice. In fact, the team is investigating several color options that provide accessible contrast and visual separation. There are times when a lower contrast choice can be defended.

4 form inputs with various text contrast options
Four different options for presenting values and descriptive text.

Intuit’s goal is to reduce the customer’s need to enter data. To this end, we use artificial intelligence to prepopulate form data. This can significantly increase the efficiency of creating a tax return or sending an invoice to a customer. But this brings up the conflict between inputs that have pre-filled data and placeholders. Customers found it confusing when forms had a combination of inputs with data and placeholders, they tended to skip the inputs with placeholders, as they looked like values. So Intuit uses a lower contrast placeholder color. It’s marginal on readability, but reduces the confusion between what is a value and what is a placeholder. Ultimately, Intuit’s Design System prioritizes moving the placeholder text out of the input and using a secondary string below the input. This removes the potential of confusion and makes the descriptive text available to everyone. We also use aria-describedby to surface that additional information to screen readers when the input has focus.

Low contrast placeholder text also makes it critical to not use placeholders as form input labels. They are meant to be suggestions, not labels.

Visual Hierarchy

Designers use visual hierarchy to define what sections of a screen are the most important, secondary, and least important. This is accomplished with:

  • Size and Scale
  • Color and Contrast
  • Typographic Hierarchy
  • Spacing, Proximity, and Negative Space
  • Alignment
  • Repetition

It’s common to place a light background color on tertiary information, such as a footer. But be careful, that body link color may not have enough contrast when placed on a background color. This should be accounted for in the color branding decisions.

Overlapping Link Requirements

Links have multiple contrast requirements. The text always needs to be 4.5:1 against the background color. It’s become a design standard to remove the underline on a link. This means the color is the only signifier between a link and body text. When color is the only difference, we need a 3:1 contrast ratio between the link (blue) and the body text (black). Technique G183, which states, “Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them.”

We also need to make sure a user can scan a page and know which links have been visited, focused, active, or have a mouse hover. This complicates the color choices when color is the only differentiator. Jared Smith explained this complexity in his article: WCAG 2.0 and Link Colors. His color selections are:

  • Normal: #3344dd
  • Hover/Focus/Active: #bb1122
  • Visited: #884488

Don’t Depend on Color


a:visited:after { 
    content:"\2713";
}

Color Strategies

There’s more to inclusive design than color 

Don’t alienate your design teams by only focusing on color. That is just one aspect of inclusive design and you risk alienating them. Especially when limited to an official color palette. Focus on empowering designers to consider the full spectrum of inclusive design and make yourself a resource, not a thorn in their side.

Listen to your customers

How to find valuable accessibility feedback in Slack

Designers Love Grey

Recognize the allure of grey text. You need to understand why designers reach for the low-contrast designs to have the correct vocabulary and work towards a color theme that works for everyone. Here are some articles about grey text for your research.

Color Prioritization

All color contrast issues need to be addressed. But some issues can be prioritized with project managers. Obvious changes, for instance older pages that still have grey on grey links in the footer, can be updated without much challenge. This is especially true if the older pages do not meet updated color palettes.

Simply Unreadable Text

Anything less than 2:1 is unacceptable and needs to be prioritized. Even if it represents a disabled element. This content is not readable.

Content that falls between 2:1 and 3:1 requires design justification. For instance, it is a disabled button or placeholder text. If the design needs to be updated if there’s insufficient justification.

Start a conversation

Determine why content uses something between 3:1 and 4:1.

  • Is it a heading?
  • Is it disabled?
  • Is it an icon or logo?
  • Because that’s what others are doing?

There are valid reasons for this contrast, but check to see what needs updating.

Why is contrast between 4:1 and 4.5:1? In many ways, these are the elements that take the longest to fix. Focus on what causes this and how they can be updated:

  • A branding color that didn’t consider accessibility
  • An adequate link color that fails when on a background color
  • A background gradient
  • A color that doesn’t meet the color palette

Action items

This presentation explored the potential of automated testing, working with different team members, and how to prioritize your color contrast improvements. Here are your action items moving forward:

  • Automated testing is great, but doesn’t provide scale
  • Prioritize below 3:1
    • Provide clear strategies to PM
  • Listen to your customers
    • Prioritize their complaints
  • Empower Inclusive Design
    • Don’t depend on color
    • Get involved early in color branding discussions
  • Bring Designers and Engineers together.

Published by Ted

Accessibility is more than making sure images have alternate text. I work with engineers, product managers, and designers to understand how accessibility impacts the users, set realistic deadlines, and create the solutions to provide a delightful experience to all users, regardless of their physical, sensory, or cognitive ability.

Join the Conversation

4 Comments

  1. Ted –

    Thanks for the great video! I’d like to address your incorrect representation of how WAVE is calculating the contrast errors.
    1. WAVE does, in fact, analyze the fully rendered page after styles and scripting are applied.
    2. WCAG requires that elements have defined (or inherited) foreground AND background colors – https://www.w3.org/WAI/WCAG21/Techniques/failures/F24.html
    3. The instances that you describe from intuit.com never have sufficiently defined foreground and background colors, but instead rely on background images to provide the sufficient contrast.
    4. When background images are disabled or do not load, all instances identified by WAVE are presented as white text on a white background (easily tested by disabling the page images). These make the text entirely inaccessible to some users, especially those that override page colors or disable images or are in very low bandwidth environments. These are WCAG failures, and are thus accurately identified by WAVE as such. Simply defining sufficient fall-back colors in CSS (as WCAG requires) would address these issues and the WAVE errors would no longer be present.

    I agree that the one on Google does not pose an end user issue, though automated tools can’t really differentiating meaningful content from non-useful content.

    Regarding the “sense of scale” and YouTube example, the WAVE API and the Million report lookup function both provide an error density metric that weight page errors/alerts with accessibility features, number of page elements, etc. This provides a weighting of the number of likely or potential issues with accessibility features and content density. These types of weightings are far from perfect, but there are ways to automatically get some measures of end user impact and error tolerance.

    I would suggest that there are many with low vision that would not agree with you that 4.42:1 is “to the naked eye accessible.” It may be to YOUR eye, but not everyone else’s – thus the need for defined and user-research-based thresholds. I agree, however, that it can be difficult that WCAG treats all contrast failures the same (like WAVE identifies all WCAG contrast failures as equal failures), and that the WCAG contrast formulas need to be refined and updated (I’ve been strongly advocating this for at least a decade – see https://www.youtube.com/watch?v=PlqLtne-Leg). And I absolutely agree that automated tools don’t tell the entire story – that’s not their intent or purpose. I’d be happy to hear ideas on how WAVE can be improved.

  2. Thank you Jared for your feedback. On the Intuit side, we’re updating the site to use a darker background color on lazy loaded areas, as there is a section that loads with a light grey block and white text. This was also caught by Axe. We’re also working on an animation that could be improved with another section. Automated testing is important and I don’t want to downgrade that.

    I appreciate the pride you have in WAVE and have great respect for WebAIM and Wave’s impact on global accessibility. My goal was to recognize how to interpret these tests and work with designers, project managers, and developers. You would approach the YouTube team differently, knowing there’s just a single string, than a site with hundreds of issues.

    I also should have been more clear about the 4.42:1 comment. I meant the difference between 4.42:1 and 4.5:1. This is a very small difference that will be detected by automation but most people would not detect. But as you said, we don’t design for most people, we design for all people.

  3. Thank you for your reply. And for your efforts to address some of the items identified on your site. Human interpretation of automated results is critical, especially for contrast failures, and you cover this extremely well in your wonderful presentation.

    We’re very keen on avoiding false errors in WAVE, but I don’t believe your video identifies any based on WCAG and WCAG documentation. If I’m wrong, please clarify and I’ll take a closer look. There is, of course, some subjectivity in exactly how WCAG is applied in these types of edge cases (thus the need for human interpretation) – and computers are inherently bad at edge cases and interpretation.

    We’ve considered methods to provide weightings for errors, but ultimately it tends to come down to favoring one disability type over another – and that just doesn’t work well. Even error density (number of errors by number of page elements) is problematic – if you want to improve your error density, it’s easier to add more page elements than decrease the number of accessibility errors (more details at https://webaim.org/projects/million/#errors).

    I fear that if WAVE (or other tools) provided some differentiation between WCAG failures (say 4.42:1) and significant WCAG failures (say 2:1), or softened the indication if there were fewer contrast errors (your YouTube example), this could cause WAVE users to ignore some failures (maybe the user is looking for the copyright link on YouTube) or favoring disability types (we’ll just address the issues that impact users that have REALLY bad vision, and ignore the couple billion that have kinda bad vision).

    I really appreciate the dialogue!

  4. My only note was the Google home page had a dot that included aria-hidden=”true”. Should that have been excluded from the tests?
    My first thought was it shouldn’t have been included in the color contrast tests. But then I remembered you could have an SVG icon with aria-hidden=”true” and aria-label on its parent button. So it should be tested, as it is still content.
    I don’t think WAVE should change rules based on how close a color contrast is to 4.5:1. That’s the job of the person interpreting the results.
    Your earlier comment prompted me to finish the job and post the slides and text/links from the presentation.

Leave a comment

Your email address will not be published. Required fields are marked *