Update color palette accessibility checker

[stephanieosan]

Which page is this about? Color

What kind of issue is this? Content/tech issue

Describe your issue The 3rd-party color palette accessibility checker we link to is no longer live (link throws a 500 error). We need to find an alternative to this, ideally that can replicate the behavior of our previous palette contrast checker. There are many color contrast tools available online but few of them support pre-loading them with a color palette, a feature we need.

Add any additional background info as needed

See the relevant discussion.

Should be updated on the following pages:

• Color
• Fonts

[contolini]

I loaded our colors into here: https://contrastchecker.com/?swatch_session=1612474035691

@anselmbradford @Scotchester Does the above link suffice?

[Scotchester]

I loaded our colors into here: https://contrastchecker.com/?swatch_session=1612474035691

@anselmbradford @Scotchester Does the above link suffice?

Unfortunately, I don't think so. It only shows each color on white. But loading every possible color combination at once would be ridiculous. (Also, wow, the sample text is tiny.)

[natalia-fitzgerald]

I pulled the relevant comments from the Mattermost chat on this from April 2021. The next step would be to access these options and select the one that best suits our needs.

Options @contolini posted:

• some other options as well: https://github.com/oomphinc/colorcube#alternatives-other-great-tools-that-provided-inspiration

Options @Scotchester posted:

• Not quite the same, but pretty cool: https://oomphinc.github.io/colorcube/. Can it auto-populate a color scheme? Hmm, maybe not as currently coded. Looks like it just submits via JavaScript without populating URL params.
• https://github.com/darekkay/a11y-contrast
• Looks like you could slooowly load our palette into the history of https://contrastchecker.com/ and then share that.
• https://onefrankguy.github.io/palette-a11y/ could also be good to fork/contribute.
• This is clunky, but functionally seems somewhat promising: http://www.daniel-soltis.com/palette-creator/. A different version that might be easier to use: http://www.daniel-soltis.com/contrast/ Only displays the color values in RGB, though, which is annoying.
• Not what we're looking for, but very cool: https://stylescratchpad.firebaseapp.com/
• Not perfect, but promising: https://accessiblecolors.app/ (GitHub: https://github.com/codewithkyle/accessible-colors)
• Not what we're looking for, but very cool: https://stylescratchpad.firebaseapp.com/
• And finally, a node package that we could use to power our own custom thing, if we wanted to go down that road: https://github.com/jameelmoses/is-contrast-checker

[sonnakim]

I didn't see the original tool, but is this the kind of thing we're looking for? @nataliafitzgerald2 @contolini

[Scotchester]

I didn't see the original tool, but is this the kind of thing we're looking for? @nataliafitzgerald2 @contolini

❗ That looks awesome!!

[sonnakim]

Cool, thanks @scotchester! (We miss you!!)

[natalia-fitzgerald]

Hi @sonnakim I took a look at the tool and I have some thoughts. This tool does do a lot of what we would want but I wonder whether it provides so much information that the key information that a user would need to make a sound decision about their type would be lost. It is a pretty overwhelming output.

Some of the things I'd be looking for in our visualization:

• Contrast ratio for small versus large type (and that this information is easy to locate)
• Which combinations pass AA (large vs small type)
• A definition of what we consider to be small and large type. WCAG only includes type sizes in points but I think that in the previous tool (or somewhere else) @Scotchester had documented a pixel translation. We'll have to track that down.
• A list that is simple and not overwhelming that helps a less fluent user to make type color decisions that are both compliant and on brand.
• I don't have a screenshot of the tool that @Scotchester built but I think that everything appeared on the screen at once without the need for horizontal scrolling. Do we have any screen shots of the original tool for reference?

I think it would make sense to simplify the output as much as possible in order to make it most applicable to the work. So I wonder whether a tool that includes only the most realistic combinations would be more helpful.

• In the page content within the Design System we include "Fully accessible combinations," "Non-accessible combinations," and "Undesirable combinations." I imagine that as an exercise we could sort all of the combinations into these 3 categories and then decide which information is worth visualizing for the user/most helpful.
• Our primary goal is to make type easy to read for our users. So all type color decisions should be made with this in mind.
• In the majority of cases of type in our work we stick with white, gray, or black type.
  • One exception to this is that we use some type colors for interactive elements. We use Pacific for links/buttons, Teal for visited links, Navy for active links/button, Red for destructive links/buttons but in these cases we always use white text on the colored background or colored text on a white background.
• It's helpful to show green type on white and white type on green because this is our brand color and users will be interested in whether this is contrast compliant for large and small type.
• In general, we don't place type of one color on a background of a different color - even if there is sufficient contrast (for example teal type on a gold background). So it may make sense to not show these types of combinations. This would reduce the number of combinations by a lot.
• For instances where we have a colored background, most notably hero graphics, social media graphics, featured content modules, and videos the best practice is to place white type on a dark background or black text on a light background (ensuring that the combinations have the proper contrast ratio).
• It is not brand compliant to place green on black or black on green, even when there is sufficient contrast.

Maybe as a first step (MVP) we can use the tool that @sonnakim has populated so that in the near term we don't continue to have a dead link on the Design System page. And, as a next step we can try to develop something that is more specific to our goal of providing users with a tool for selecting type colors that have the proper contrast ratio AND are aligned with our brand guidelines and best practices.

[sonnakim]

@nataliafitzgerald I wonder if there's a limited number of type/background color combinations that are both brand complaint and accessible, and if so, perhaps we add them directly to the color page in the Design System. So, the next step would be to see how many combinations we're actually talking about. It may not be worth setting up a third party tool if it's easy enough to add these combinations directly to the Design System.

[sonnakim]

@nataliafitzgerald I think there are way too many color combinations for us to be able to add these manually to the DS...but I've looked more closely at the tool, and was thinking that for an MVP, maybe we can show three different links:

AA conformant combinations of:

• White, grey, or black type against our color palette
• White, grey, or black type against our color palette, for type sizes 18 pt or larger
• Green type on white/light grey, for type sizes 18 pt or larger

Looking back at your comment, the issues with this MVP solution are, first, that the first two links above still show black and dark grey type on green, which is not brand compliant—but perhaps we can add these links to the Design System with a warning? And, second, that we still don't have a pixel translation for points. Anyway, let me know what you think.

[caheberer]

I'm curious if there's a more simplified solution. Personally, I never used the previous tool because I knew the general rule that black text on any of our colors at 20% and white text on any of our 100%+ saturation colors (except gold) is accessible. If I wanted to use a different color or tint I would check that combination individually on the WebAIM tool. It rarely comes up because as Natalia mentions above we don't recommend using colored type on a colored background, or even colored type much at all. Most colored type that we use are embedded in our patterns.

Would it be easier to provide general rules on the design system like this?

[caheberer]

During scrum we determined I would move forward with this proposed solution. Below is a mock-up of how I think the Fonts page could be updated to include more simplified guidance around accessible color combinations.

While we are at it, what do we think of changing the title of the page from "Fonts" to "Type"?

@sonnakim @designlanguage @ajbush mind letting me know what you think?

This would follow "Spacing" within the "Guidelines" section of the Fonts page.

[sonnakim]

@caheberer Nice! I like the simplicity and focus of what you've done here. It might be worth running this by one of the production designers as well to get their thoughts. Just a few small comments:

---

I like the idea of renaming the page to type — it does seem more appropriate. If you do rename it, I think we should add a redirect from the existing URL, as folks may be linking to this page from elsewhere. I think @brandon-rusk has handled redirects before, so you can let him know if you do rename it. I believe the nav will also have to be updated to link to the renamed page — that's something that you should have edit rights to do, but let me know if you run into issues.

---

Should we add the sentence "the only exception to colored type falls within illustration or other graphics" to the "Colored Type" section, and then add a jump link? Or combine these into one section? Otherwise it could sound like a contradiction. If there's a common enough use case for adding colored type in graphics, maybe we should make that clear, so there's no confusion.

---

I think "saturation of 100% and above" is a typo?

---

Should this say "Web Content Accessibility Guideline (WCAG) standards "? It's unusual to see "WCA" as a standalone acronym

[caheberer]

Thanks for the feedback, @sonnakim I'll work on incorporating your suggestions.

[caheberer]

Here's the revised version. @sonnakim let me know if you have any additional feedback. I'm going to ping additional designers/production designers to take a look as well.

.

[sonnakim]

@caheberer looks great!

[caheberer]

AJ reviewed and liked the simplicity. He also suggested incorporating the inclusion of "A few colors allow for slightly darker saturations while still maintaining accessibility." To cover the instances where we use darker saturations with black type, like in heroes.

I made the updates and published the page.