Poor colour contrast in form elements while connecting Jetpack

[simison]

While connecting Jetpack site from WordPress.com, I see this:

"Setting up" button seems like I should see that text even if the button is disabled and in "loading" state; currently it has too low colour contrast even for my healthy eyes and good screen. :-) In other places in this flow we pulsate between visible and grey text when something is happening (sorry no screengrabs about this).

The address in disabled input is also pretty low contrasty.

Later in the flow also these inputs could have better contrast:

This is really just generic issue with form buttons (see https://github.com/Automattic/wp-calypso/issues/26982) but I feel that in this flow we could work around the issue of using disabled form elements in some way.

FYI @tyxla @keoshi

[simison]

https://webaim.org/resources/contrastchecker/ is excellent tool to check these pass.

[tyxla]

Thanks @simison! What could we do about these @keoshi @jeffgolenski?

[simison]

Especially this note by @drw158:

Disabled inputs are being used to convey information that is meant to be read. Important info should not be placed in a disabled input because disabled elements are not meant to be legible.

via https://github.com/Automattic/wp-calypso/issues/26982#issuecomment-474396291

[keoshi]

Thanks for bringing this up @simison !

This is really just generic issue with form buttons (see #26982)

I agree that we should take care of this higher up the chain and benefit from the changes downstream.

but I feel that in this flow we could work around the issue of using disabled form elements in some way.

I'm thinking we could do without that URL form once a valid URL has been submitted and have a more visual UI for that intermediate step, but that also feels more complex than what we're able to handle right now. What did you have in mind?

[simison]

but I feel that in this flow we could work around the issue of using disabled form elements in some way.

I'm thinking we could do without that URL form once a valid URL has been submitted and have a more visual UI for that intermediate step, but that also feels more complex than what we're able to handle right now. What did you have in mind?

Here's a recording of the flow I took: https://cloudup.com/czVZnjUpym3

I'd imagine the part with "setting up" and URL input could also be part of some other flow, so I don't actually see the full picture here?

Otherwise, the flow could just directly jump from this:

To something that looks like this:

Currently, there are two visually different screens (and a quick flash of W logo, so three) all basically telling "please wait".

If the URL input + button step has to stay, perhaps instead of a disabled button you could just show the text, perhaps with rolling animation like in URL input?

URL input also could disappear at that point and just show the URL as a text.

Thoughts?

[simison]

Here's an example from Mailchimp signup form:

https://login.mailchimp.com/signup/

First disabled state is when we don't really need to know what it says on the button and we haven't yet filled the form.

Then we've filled the form.

And finally we're waiting for form to send. There's a spinning animation.

[keoshi]

The improvements on the flow all look really good and we're considering some on the Figma file I liked to on Slack, but they're out of the scope of this issue so let's create a new one for that.

As for the pattern example from Mailchimp, that looks interesting and is certainly something we could champion and push the improvements upstream! Two notes:

• I've checked their code and it doesn't seem optimal though, as they're not disabling the button allowing for sequential requests (not sure if that would fly in JPC).
• Maybe we can accomplish the same effect by adding an extra class to the last disabled state and override the styles then.

[keoshi]

Maybe we can accomplish the same effect by adding an extra class to the last disabled state and override the styles then.

Here's a quick prototype showing that:

https://codepen.io/keoshi/pen/bZxPrP

[github-actions[bot]]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

[keoshi]

I'll be looking at this in the upcoming HACK week.

[jeffgolenski]

You're a champion, @keoshi

[keoshi]

Created a PR to sort this issue here: https://github.com/Automattic/wp-calypso/pull/50849