-
Notifications
You must be signed in to change notification settings - Fork 45
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
[FEATURE] Add Link component to define link styles #129
Comments
I'm not sure what else to do with this feedback, so I'm going to put in here - lmk if there's a more appropriate place!! ❤️ While working on the preview for collections, @pepopowitz and I have run into some difficulty using https://app.zeplin.io/project/5aabc5d2e01881c81138e58e/screen/5c5cadd021ae342cd2903443 We've got a It's sorta hard to see, but the hover is underlining and doing so in black. And it behaves this way because we've used the I've got a commit on a fork of palette that demonstrates this in the docs for Link: Here's what I think needs to be addressed:
Ok that's my feedback, hope this helps and I'm happy to talk through this if anything is confusing!! 🤗 |
All great points here. I think those all are design questions. The current link was built to the spec above which obviously did not seem to consider 'black on black' case. The 'noUnderline` prop was also taken directly from zeplin spec: https://app.zeplin.io/project/5acd19ff49a1429169c3128b/screen/5afc758c09a18d3d0f176edd I agree that it is a bit misleading this name.... |
Component Name
Link
Zeplin link
https://app.zeplin.io/project/5acd19ff49a1429169c3128b/screen/5afc758c09a18d3d0f176edd
Product team
all
Design lead
@nicoleyeo
Checklists
Design
For Tokens
Color, type, spacing, icons, etc
Is it serving a purpose? (is it needed or just purely decorative?)
Can it be merged with any existing styles on the site?
Has it been pressure-tested in all instances?
Does it meet accessibility standards? (min type size, color contrast)
For Elements
Buttons, links, loaders, inputs, dropdowns, etc
Is it using up-to-date tokens from above?
Have all states been captured? (hover, selected, disabled, focused, normal, thinking, errors)
Have all transitions/animations been defined?
Is it useable? (Considering touch targets, screen sizes)
Is it consistent with the rest of the visual system? (Corner radius, stroke weight, form, shadow, opacity, etc)
Does it meet accessibility standards? (is it keyboard navigable, does it have required accessibility markup)
Does it render and function properly in Artsy supported browsers?
For Components
Nav, modules, modals, cards, etc
Is it using up-to-date elements and tokens from above?
Does it communicate clearly? (Copy, writing style/tone)
Is it flexible? (Internationalization, text wrapping)
Is it logical from a UX perspective? Does it follow paradigms set on the rest of Artsy?
Has responsive behavior at all breakpoints been defined?
Have all transitions/animations been defined?
Does it meet accessibility standards?
Does it render and function properly in Artsy supported browsers?
Engineering
Accessibility
Do all images and multimedia have
alt
ortitle
tags?Are semantic elements used appropriately (
nav
,button
, etc)?Are new components keyboard-navigable?
Are hover interactions available by other means?
Are
aria-
attributes included where appropriate?Has a Chrome Devtools accessibility audit been performed?
Compatibility
Has the new component been reviewed in Browserstack:
Desktop Chrome
Desktop Edge
Desktop Safari
Desktop Firefox
Android
iOS
The text was updated successfully, but these errors were encountered: