Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI: some elements have too low color contrast #8935

Open
Hypnosphi opened this issue Nov 24, 2019 · 8 comments
Open

UI: some elements have too low color contrast #8935

Hypnosphi opened this issue Nov 24, 2019 · 8 comments
Assignees

Comments

@Hypnosphi
Copy link
Member

Hypnosphi commented Nov 24, 2019

See https://dequeuniversity.com/rules/axe/3.4/color-contrast?application=axeAPI

Links

Primary

image

Element has insufficient color contrast of 2.62 (foreground color: #1ea7fd, background color: #ffffff, font size: 12.0pt (16px), font weight: normal). Expected contrast ratio of 4.5:1

Suggestion: change primary link color to #027ac5
image

Secondary

image

Element has insufficient color contrast of 2.84 (foreground color: #999999, background color: #ffffff, font size: 12.0pt (16px), font weight: normal). Expected contrast ratio of 4.5:1

Same for subheadings
image

Suggestion: change secondary link and subheadings color to #6f6f6f. Change subheadings font-weight to 700 for compensation
image
image

Selected sidebar item

image

Element has insufficient color contrast of 2.62 (foreground color: #ffffff, background color: #1ea7fd, font size: 9.8pt (13px), font weight: bold). Expected contrast ratio of 4.5:1

Suggestion 1: change background to #027ac5
image
Suggestion 2: change test color to #333333, change background to #81cefe
image

JSX highlighting

image

Element has insufficient color contrast of 3.63 (foreground color: #2b91af, background color: #ffffff, font size: 12.0pt (16px), font weight: normal). Expected contrast ratio of 4.5:1
Element has insufficient color contrast of 3.99 (foreground color: #ff0000, background color: #ffffff, font size: 12.0pt (16px), font weight: normal). Expected contrast ratio of 4.5:1

Suggestion: change tag highlight color to #26809c, change attribute highlight color to #eb0000
image

Button

Primary

image

Element has insufficient color contrast of 3.23 (foreground color: #ffffff, background color: #ff4785, font size: 9.8pt (13px), font weight: bold). Expected contrast ratio of 4.5:1

Suggestion 1: change background to #eb004e
image
Suggestion2: change color to #333333, change background to #ff80aa
image

Secondary

See Selected sidebar item

Outline primary

image

Element has insufficient color contrast of 3.23 (foreground color: #ff4785, background color: #ffffff, font size: 9.8pt (13px), font weight: bold). Expected contrast ratio of 4.5:1

Suggestion: change text color to #eb004e
image

Outline secondary

See Link / Secondatry

Bagde

image

Element has insufficient color contrast of 2.14 (foreground color: #66bf3c, background color: #e1ffd4, font size: 8.3pt (11px), font weight: bold). Expected contrast ratio of 4.5:1
Element has insufficient color contrast of 2.72 (foreground color: #ff4400, background color: #feded2, font size: 8.3pt (11px), font weight: bold). Expected contrast ratio of 4.5:1

Suggestion: change text colors to #427c27 and #bd3200
image

@domyen
Copy link
Member

domyen commented Nov 26, 2019

Thanks for the a11y audit! Would like to update the color palette to something that's perceptually similar to the current palette but with greater accessibility.

I'm researching Colorbox.io from Lyft and Stripe's recent color system article to inform this.

Edit: made a new issue for the SB design system to do this experimentation in a spike before integrating it in the main Storybook UI.

@roblevintennis
Copy link

roblevintennis commented Oct 9, 2020

Thanks for the great tool Storybook team! @domyen I'm glad to see you were making some progress on this. However, that's almost a year back and I'm wondering why it hasn't been fixed yet? Hoping we can prioritize that if possible :)


So, I was about to file my own ticket but I'm glad this one is open. I think any tool that helps with component driven development ought to be an example of best practices itself—especially for a11y.

But, there's a specific dev ux motivation to this as well, and it's for this use case…

As a developer, I'd like to be able to use tools like Lighthouse to verify my components, without requiring me to use Storybook's addons. Storybook should not compound the already confusing a11y dev experience by adding it's own errors.

Repro:
Run a simple component through Lighthouse to get the page results for contrast.

Expected:
I should see no Backgorund and foreground colors do not have a sufficient contrast ratio errors for anything else but said component

Result:
I see 5 Storybook related errors.

image

Having audited my own site recently, I can tell you these would be quite easy fixes involving dragging a slider slightly darker until it meets required ratio.

Thanks again for the tool. We love it. Just would love if you make fixing contrast within Storybook's own chrome a priority 👍 -- thanks!

@Hypnosphi
Copy link
Member Author

@roblevintennis you probably want to audit your own components only. To do that, you can open preview frame in a new tab using "open in new tab" icon in top right corner

@shilman shilman added the PN label Oct 9, 2020
@roblevintennis
Copy link

Thanks @Hypnosphi -- I'll definitely keep that in mind 👍

@roblevintennis
Copy link

Love storybook and the obvious benefits it brings to the component development ecosystem. But…

Today, I use storybook-addon-a11y for testing my own components and it seems to work well enough, but I really don't see why such a prolific tool like Storybook, itself, shouldn't get accessibility at least mostly correct itself when it comes to things like color contrast or html structure, etc. I can understand if there's some quirky iframe interaction that messes up a11y and it's hard to fix but not for something like color contrast.

The whole reason for being is to help folks develop correct, bug free components in isolation. One of the most frequent issues us FE devs have is skipping a11y checks and it would be great if SB would lead by example here.

Here you can see my component is not failing any a11y tests but storybook itself is if I wire up the IBM checker:
image

I bet half of these violations could be solved by using a <main> tag in the right place, or simply choosing some slightly different colors, etc.; not hard things to fix. I'm just wondering why coming back to this ticket almost a year later there's no apparent interest in this ¯_(ツ)_/¯

@domyen
Copy link
Member

domyen commented Oct 28, 2021

Storybook is composed of a bunch of contributors from around the world. If you see an improvement, the community (and me!) would def appreciate your help.

Would you be interested in submitting a PR to address some of the issues you found @roblevintennis?

@roblevintennis
Copy link

If I get time I will. It's limited at the moment. Perhaps a core contributor will get to it before I can.

@shilman shilman removed the PN label Apr 24, 2023
@shilman shilman removed the todo label Jun 20, 2023
@amarhefka-artech
Copy link

Just wanted to give this thread a bump, as it's been several years. We recently conducted an audit and noticed quite a lot of color contrast violations in the out-of-the-box palette—and not just for static elements, but also for visual focus indicators (VFIs) when you tab through the interactive elements. Happy to provide more detail if necessary, but it seems like there's plenty of pending work here already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants