Accessibility issue reported

[cdpestitschek]

Context: We are working on some fix and improvements since we were contacted by one of our clients who, during an accessibility audit, had some points that did not meet the accessibility standards.

Issue reported: When hovering, the icon does not have enough contrast with the background color in the hover state.
JIRA ticket

Evidence:

I am opening this thread to inform you that the token proposed for the over is not currently meeting the accessibility requirements. I am also requesting assistance in finding a solution, given the limitations of the available token palette.

Alternatives found in Paste (it would solve just the light mode)
tokens - these pass light mode but not dark mode:
$color-background-overlay
Token value: • rgba(96, 107, 133, 0.5) • #606B8580
$color-background-stronger
Token value: • rgb(136, 145, 170) • #8891AA

One suggestion from @hannah (developer working on it)

Could we have the slightly differing dark and light modes backgrounds, but have the hamburger menu white for both (an almost indistinguishable difference) and then make the hover:
$color-background-stronger
Token value: • rgb(136, 145, 170) • #8891AA

Could you give us any suggestions or tell us if you agree with the suggested proposal?

Looking forward to hear back from you :)

[dosubot[bot]]

🤖

Hey there, @cdpestitschek! 🎉 I'm Dosu, a bot here to sprinkle a bit of humor and some byte-sized help while you wait for a human maintainer to swing by. Though I might not run on caffeine or have human quirks, I'm programmed to help solve bugs, answer questions, and guide you on becoming a contributor. Consider me your digital sidekick in the coding realm! I'm diving into your issue about the accessibility concerns with icon contrast, and I'll get back to you with a more detailed answer shortly. Hang tight!

[TwilioPasteBot]

Disclaimer: This is a very experimental bot using OpenAI's GPT-4. The answers may not be correct, a human will review the answer and update it if necessary.

---

Sorry, I don't know how to help with that.

I did do a search though, and I managed to find these other Discussions that might be similar or related to your question. Give them a read to see if they answer your question. If they do, head back here and update this discussion and mark it as answered, pointing others to the related discussion:

• Acessibility (updated: 08/10/2022, similarity score: 86%)
• Inconsistent color tokens for text/icons - Answer (updated: 08/10/2022, similarity score: 86%)
• Email - UI issues in dark mode of Flex (updated: 06/17/2022, similarity score: 85%)

[dosubot[bot]]

🤖

Based on the information you've provided, it seems like you're on the right track with your proposed solution. The idea of having slightly differing dark and light modes backgrounds with the hamburger menu white for both, and the hover as $color-background-stronger (Token value: rgb(136, 145, 170) / #8891AA) could potentially solve the issue.

However, to ensure that your solution meets the accessibility requirements, I would recommend using the contrast checking functions provided in the Paste design system. These functions can be used to check the contrast ratio between different color tokens in your theme.

For your specific issue of insufficient contrast between the icon and the background color in the hover state, you can use these functions to check the contrast ratio between your proposed hover color ($color-background-stronger or rgb(136, 145, 170) / #8891AA) and the color of your icon (white).

Here's an example of how you might do this:

import { getContrastRatingsOfTokensWithUIControlContrastRequirements } from "@twilio-paste/design-tokens";

const contrastRating = getContrastRatingsOfTokensWithUIControlContrastRequirements({
  backgroundColors: { 'color-background-stronger': '#8891AA' },
  textColors: { 'color-text-icon': '#FFFFFF' },
});

console.log(contrastRating);

This will return an array of contrast ratings for all combinations of background and text colors. You can then check these ratings to ensure that they meet the minimum contrast ratio for accessibility (3:1 for graphical objects and UI components).

If the contrast ratio is below the minimum, you might consider adjusting the colors of your icon or hover state to increase the contrast. For example, you could use a darker color for your icon in light mode, or a lighter color for your hover state in dark mode.

You can find more information about these functions in the themeContrast.spec.ts file in the Paste repository.

Remember, the specific accessibility requirements for contrast ratios in the Paste design system are:

1. Text color contrast ratio requirement of 4.5:1
2. UI control contrast ratio requirement of 3:1

These requirements are outlined in the UseThemeContrastCheckReturn interface in the useThemeContrastCheck.ts file.

I hope this helps! If you have any other questions or need further clarification, feel free to ask.

Sources

• packages/paste-color-contrast-utils/tests/themeContrast.spec.ts
• packages/paste-theme/src/useThemeContrastCheck.ts

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[SiTaggart]

Hi there

I don't believe your customer report is correct.

The screenshot states "focus state" but the focus state has a 3 pixel border color change that not only passes based on it not being a color only change, but also the color of the border to the background of the top bar is greater than 3:1.

If they mean "hover" I don't believe that is correct either. The contrast of the bounding box isn't part of the success criteria anymore, if the content passes contrast of 3:1 or higher on the background of the control and the background of the container, which the hamburger icons does in both instances.

The requirement for the contrast between states such as default to hover was also moved to AAA, potentially removed altogether.

TL;DR; what you have is technically accessible.

It doesn't follow Paste button guidelines, which is obviously more clear cut and far better as we change more things about the appearance of a button on hover and focus.

[SiTaggart]

All the details can be found here under boundaries https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

This success criterion does not require that controls have a visual boundary indicating the hit area

If a button with text also has a colored border, since the border does not provide the only indication there is no contrast requirement beyond the text contrast

For Paste based controls we do try to meet the AAA requirement for making the change in state be at minimum 3:1 contract ratio, or change physically, to the previous state. Examples include:

• If a hover state changes the color of an icon we make sure the contrast between the default color and the hover color is 3:1 differnce
• A hover state might include adding a border, changing size, physical characteristics that aren't just color, and those changes are at least 3:1

[hjbrown11]

Hi Simon, thanks for this!

Maybe it's my misunderstanding, but doesn't the following line imply that we would need 3:1 contrast between background, hover state and icon? - 'any visual information necessary to indicate state, such as whether a component is selected or focused must also ensure that the information used to identify the control in that state has a minimum 3:1 contrast ratio.'. Or is it just saying that the hamburger and banner colour need to still have the sufficient contrast? Our customer had an auditor who highlighted these issues, so I want to be certain and be able to point to the guidance confidently in our response.

My understanding of the two quotes you've mentioned are relating to whether a button requires a border/edge, rather than relating to the hover specifically. Our focus state seems okay as you say, because of the border on focus, but I'm still struggling to understand if our hover is sufficiently acceptable. It is possible for us to implement a change of colour as I suggested previously, so I can do this if needed.

[SiTaggart]

I think it's different, it's talking about being able to identify the control whilst in state, not the state of the control. There's an example further down the page that is relevant

It's talking about identifying the control, not the hover treatment.

Focus indicators are covered by a different success criteria.

[hjbrown11]

Ah okay great! Thanks for the clarification

[SiTaggart]

If you're super worried about it, slap the focus treatment on hover.