add warning and error tooltips

[jasonbasuil]

closes #1125

Warning: https://62d040e741710e4f085e0647-dcwnoaugyn.chromatic.com/?path=/story/components-tooltip--warning-icon
Error: https://62d040e741710e4f085e0647-dcwnoaugyn.chromatic.com/?path=/story/components-tooltip--error-icon

• Adds a warning and error Tooltips, set via iconClasses
• Removes green Tooltip as it is not currently used
• Renames gray Tooltip to neutral

Primary: Gabe
Secondary: Alex

[jasonbasuil]

neutral seemed a little more semantic since the default color is blue-500 and is meant to stand out less. Will rename this class when cutting over

[AlexAlt]

looks pretty good, thanks for the quick update here!

[gabescarbrough]

This color doesn't meet accessibility guidelines for color contrast

Amber is a tough color to meet WCAG AA for against white. This same color would pass AA against black.

Could we make the exclamation point black for this variant? One way you could do it would be using a pseudo-element to be able to set the background color behind the icon.

.Tooltip__icon--warning::before {
    background: black;
    border-radius: 100%;
    content: '';
    height: .7rem;
    margin-left: 1px;
    margin-top: 5px;
    position: absolute;
    width: .7rem;
    z-index: -1;
}

[jasonbasuil]

Nice callout. Would agree that it is kinda hard to see anyways. Good question for @wenzeng4 if you wanna chime in design wise

[wenzeng4]

Ah, I mistakenly assumed that our orange had been accessibility tested already. I'm going to regroup with the design team and propose changing our orange color palette to ensure that it passes contrast checks for our intended use. Will update tomorrow!

…

On Wed, Jan 10, 2024 at 11:54 AM Jason Basuil ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/Tooltip/Tooltip.scss <#1126 (comment)> : > color: $ux-gray-800; } - &--primary { - color: $ux-emerald; + &--warning { + color: $synth-warning-amber-alternate; Nice callout. Would agree that it is kinda hard to see anyways. Good question for @wenzeng4 <https://github.com/wenzeng4> if you wanna chime in design wise — Reply to this email directly, view it on GitHub <#1126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANXXUJDNDMI2LOHTPFTTY6TYN3WWRAVCNFSM6AAAAABBVG4D3KVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQMJUGA2DKNZTGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- ☁☮☺☂♫

[jasonbasuil]

Passes AA and should be good as we shouldn't really expect to use white text on this background.

[jasonbasuil]

Talked to Wen and we agreed that the box-shadow made the tooltip look fuzzy on focus, so we decided to remove it to make it look a little cleaner. Keeping the default focus state for tabbing focus.

Screen.Recording.2024-01-11.at.10.50.26.AM.mov

[gabescarbrough]

Passes AA and should be good as we shouldn't really expect to use white text on this background.

Are you considering it passing because it passes for Graphical Objects and User Interface Components?

That is for "non-text contrast", which has the more lenient 3:1 ratio (the same as large text) as opposed to 4.5:1 for normal sized text).

I guess this is kind of an edge-case in the guidelines. I would consider ! to be text, since it is punctuation, so I would expect it to pass WCAG for normal size text even though it is inside an icon. The difference between circle-exclamation and circle-question is just the text character within the circle so it seems to me that we would judge it against the text criteria, especially since the character is so small.

WCAG does call out a very similar example to this
and recommends the 3:1 ratio but it is for a phone icon which is a much more distinct shape than ? vs ! and isn't a text character.

The updated color passes AA for large text, which for non-bold text is 24px or larger.

The font size of this icon is 14px, so the text within the icon is even smaller. #f16e00 fails contrast checks for normal sized text.

I don't think we're going to find an orange that passes AA for normal sized text against white. If you lower the lightness in order to get the needed contrast orange starts looking brown.

Are we opposed to the warning variant being black on amber? #f16e00 against black has a ratio of 6.97:1 and passes AA for normal text. Whereas #f16e00 against white has a ratio of 3.01:1 which doesn't pass for normal text and just barely passes if don't consider it text and just an icon. It seems like if we're in a grey area it makes sense to go for the more accessible of the two options.

For what it's worth, $synth-warning-amber-medium #ffe356 against black passes with a ratio of 16.37:1 which even satisfies AAA for normal text. That's another option if orange against black doesn't look right.

[jasonbasuil]

Passes AA and should be good as we shouldn't really expect to use white text on this background.

Are you considering it passing because it passes for Graphical Objects and User Interface Components?

That is for "non-text contrast", which has the more lenient 3:1 ratio (the same as large text) as opposed to 4.5:1 for normal sized text).

I guess this is kind of an edge-case in the guidelines. I would consider ! to be text, since it is punctuation, so I would expect it to pass WCAG for normal size text even though it is inside an icon. The difference between circle-exclamation and circle-question is just the text character within the circle so it seems to me that we would judge it against the text criteria, especially since the character is so small.

WCAG does call out a very similar example to this and recommends the 3:1 ratio but it is for a phone icon which is a much more distinct shape than ? vs ! and isn't a text character.

The updated color passes AA for large text, which for non-bold text is 24px or larger.

The font size of this icon is 14px, so the text within the icon is even smaller. #f16e00 fails contrast checks for normal sized text.

I don't think we're going to find an orange that passes AA for normal sized text against white. If you lower the lightness in order to get the needed contrast orange starts looking brown.

Are we opposed to the warning variant being black on amber? #f16e00 against black has a ratio of 6.97:1 and passes AA for normal text. Whereas #f16e00 against white has a ratio of 3.01:1 which doesn't pass for normal text and just barely passes if don't consider it text and just an icon. It seems like if we're in a grey area it makes sense to go for the more accessible of the two options.

For what it's worth, $synth-warning-amber-medium #ffe356 against black passes with a ratio of 16.37:1 which even satisfies AAA for normal text. That's another option if orange against black doesn't look right.

Yeah I was initially thinking "Graphical objects" or "User interface components" would encompass this, but I guess it does make sense that the svg that it is actually representing is text. The punctuation is actually pretty small to begin with and even for me it is a little difficult to see at 100% zoom.

I did talk to @wenzeng4 and we're going to do a little bit more of an audit on tooltips in general (colors, sizing, etc.), but thought it would be okay to swap out to use the triangle variation of the exclamation icon for the calendar warnings/errors in the meantime just to have the visual distinction until we find a path that makes sense on the a11y contrast.

[gabescarbrough]

I did talk to @wenzeng4 and we're going to do a little bit more of an audit on tooltips in general (colors, sizing, etc.), but thought it would be okay to swap out to use the triangle variation of the exclamation icon for the calendar warnings/errors in the meantime just to have the visual distinction until we find a path that makes sense on the a11y contrast.

That makes sense to me. Having the different shape definitely makes it way more obvious it is a different icon.

Not blocking to this at all: we should consider switching to a variant prop for Tooltip when we get to a major version bump to be more consistent with other components.

[jasonbasuil]

Not blocking to this at all: we should consider switching to a variant prop for Tooltip when we get to a major version bump to be more consistent with other components.

Yeah definitely wanted to switch to variant so we could probably do that when we revisit this.