Skip to content

USWDS - Input & Prefix/Suffix: Add disabled styles. Resolves #4913#5004

Closed
mahoneycm wants to merge 28 commits into
developfrom
cm-prefix-suffix-disable
Closed

USWDS - Input & Prefix/Suffix: Add disabled styles. Resolves #4913#5004
mahoneycm wants to merge 28 commits into
developfrom
cm-prefix-suffix-disable

Conversation

@mahoneycm

@mahoneycm mahoneycm commented Oct 24, 2022

Copy link
Copy Markdown
Contributor

Description

Preview →

Resolves #4913

Input disabled styling

Currently, disabled form elements other than button rely on default browser styles to give visual queues that form elements are disabled. Chrome and Edge very lightly dim the field, but is sometimes hard to notice. Other browsers such as Safari and Firefox do not add any visual indication that these fields are inaccessible to the user.

@amyleadem summed it up very nicely in her comment on #4322 which addresses this issue for select / dropdown components

@thisisdano @mejiaj I have included a screenshot that showcases disabled visual cues in Chrome, Firefox, Safari, and Edge for OS. This screenshot displays the following:

  • Standard .usa-select element
  • Disabled .usa-select element
  • Disabled select element without .usa-select class
  • Standard .usa-input element
  • Disabled .usa-input element
  • Disabled input element without .usa-input class

Image

I also have a link to a live demo in PR #4969 in case it is hard to glean the style differences from the screenshot.

Things to note:

  • Each browser has its own set of default styles for disabled form elements.
  • USWDS overrides some default disabled styles in a way that makes it less clear visually that the element is disabled.

I lean towards wanting to take a look at developing disabled styles for USWDS form elements that provide clearer visual cues that the element is disabled. However, we would need to be careful of poor contrast ratio and look into accessibility implications.

I agree with Amy in leaning towards developing our own disabled styles to have a consistent and easy-to-understand style across all USWDS form elements and browsers.

This PR adds disabled styles for input elements but can be extended to other form elements such as text fields, drop downs, and combo boxes if we chose to take this route.

Prefix / Suffix

As mentioned in #4913, input prefix/suffix does not inherit the input disabled style. This can be resolved by creating a usa-input-group--disabled style. The usage would be consistent with how we implement the error state with usa-input-group--error.

Prefix / Suffix are the only components that make use of the usa-input-group class so there is no worry about the styles breaking another component.

Screenshots

Before

Prefix with disabled input:
image

After
Prefix with usa-input-group--disabled and disabled input:

Screen Shot 2022-11-28 at 9 43 57 AM

@mahoneycm mahoneycm requested review from amyleadem and mejiaj October 24, 2022 15:13

@mejiaj mejiaj left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found with input prefix / suffix visual styles specifically. Added comments based on additional findings. Also, can you check the failed test in CircleCI?

Tested

  • Code style and formatting
  • Input prefix/suffix with disabled attribute
  • Adding disabled attribute to all inputs found in components under Form Inputs

Comment thread packages/usa-input-prefix-suffix/src/usa-input-prefix.twig Outdated
Comment thread packages/usa-input-prefix-suffix/src/usa-input-prefix.twig Outdated
Comment thread packages/usa-input-prefix-suffix/src/styles/_usa-input-prefix-suffix.scss Outdated
Comment thread packages/usa-input/src/styles/_usa-input.scss Outdated
@mahoneycm mahoneycm requested a review from mejiaj November 1, 2022 14:45
@mahoneycm

mahoneycm commented Nov 1, 2022

Copy link
Copy Markdown
Contributor Author

Removed styles for text input

We'll add support disabled styles for other form elements in another ticket

Screenshots go from Active inputs, default chrome styles when disabled, new styles with USWDS disabled
image

This can easily be added to other inputs such as select or combo-box.

What do you all think @mejiaj @thisisdano @amyleadem ? Something to consider implementing?

@mahoneycm mahoneycm requested a review from thisisdano November 1, 2022 18:30

@mejiaj mejiaj left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good on this component. Let's create a new issue (if there isn't one already) for extending this to other form inputs.

@mahoneycm

Copy link
Copy Markdown
Contributor Author

Issue created here: #5051

@amyleadem

amyleadem commented Nov 23, 2022

Copy link
Copy Markdown
Contributor

@mahoneycm
Looks good. I am a bit torn on the styling because it doesn't read as disabled to me from a visual perspective. But I understand that we likely want to maintain accessible color contrast ratios and I like that it matches the disabled date picker styles.

I added a comment to #5051 about possibly standardizing USWDS disabled styles since there are differing levels of contrast in disabled styles across the design system.

Additionally, our radio and checkbox disabled styles have added cursor: not-allowed in their styles. Would it make sense to add that here as well?

@mahoneycm

Copy link
Copy Markdown
Contributor Author

Originally I had set the color to disabled-light because it was closer to Chromes disabled styles. I went ahead and switched it to disabled so it was consistent to other disabled elements and added cursor: not-allowed as recommended!

@mahoneycm mahoneycm requested a review from mejiaj November 28, 2022 14:49

@amyleadem amyleadem left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mahoneycm,
I remembered that we should add the same styles for aria-disabled as well (like in PR #4783).

I also noticed that date picker no longer has styles for aria-disabled. Can you take a look to see if your fix will repair that?

Thanks!

@mahoneycm

Copy link
Copy Markdown
Contributor Author

@amyleadem I noticed that other forms include aria-disabled styles while working on my other disabled forms PR and I planned on adding them in, so I'll do that for this PR as well!

As for date picker, I'll look into it as part of #5051

@mahoneycm mahoneycm requested review from amyleadem and mejiaj December 6, 2022 19:14
@mahoneycm

Copy link
Copy Markdown
Contributor Author

@amyleadem I added aria-disabled styles and an example within the component previews.

date-picker still has aria-disabled on this branch, but I'll make sure it's included on #5051

@amyleadem amyleadem left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ This fix conflicts with the effort to remove disabled classes in #5128. Is there an alternate method for styling this component?

@amyleadem

Copy link
Copy Markdown
Contributor

Going to change the status on this issue to "Review" to allow for evaluation.

@amyleadem amyleadem left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this styling solution and I like the clarity of the variables up top, @mahoneycm! I added a few comments for your review.

Additionally, what do you think about the possibility of removing the index.js file now that the input is full width and absolutely positioned? I might be missing something, but with a little tweaking it feels like we can handle focus with CSS exclusively now. Curious to hear your thoughts!

Comment thread packages/usa-input-prefix-suffix/src/styles/_usa-input-prefix-suffix.scss Outdated
Comment thread packages/usa-input-prefix-suffix/src/styles/_usa-input-prefix-suffix.scss Outdated
Comment thread packages/usa-input-prefix-suffix/src/usa-input-prefix.twig Outdated
Comment thread packages/uswds-core/src/styles/mixins/utilities/_disabled.scss
@mahoneycm mahoneycm requested a review from amyleadem February 13, 2023 14:44
@mahoneycm

Copy link
Copy Markdown
Contributor Author

@amyleadem Thanks for the great feedback! Resolved all of your comments if you'd like to give it a double check!

Comment on lines +27 to +32
&--error,
&--success {
& input:focus {
outline-offset: units($theme-input-state-border-width);
}
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, the focus outline is placed outside of the succes/error border. This allows for the same styling

image

If we prefer to have the focus cover the success/error border, we can remove these lines

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the the outline-offset is a good consideration. Nice call.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did notice that the input border (1px) is now covered by the focus outline, whereas it was visible before. It is a small thing, but just wanted to flag the visual difference. Not sure if it needs any action.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look who's finally learning to use tokens 🤪

I experimented with trying to resolve the hidden input outline but I wasn't able to add on pixels to the units($theme-input-state-border-width) function and the input is being set by like so:

%block-input-styles {
  @include u-border(1px, "base-dark");

Maybe if they're both variables I could add them within the function?

@mejiaj mejiaj Feb 15, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, good consideration. I was initially put off by the level of nesting, but it makes sense. Moving forward we should be cautious with too much nesting.

Usually it's best practice to move your grouped selectors up before the individual ones. The & isn't necessary when it's a child element.

  &--error,
  &--success {
    // No need for the preceeding `&` here.
    input:focus { 
      outline-offset: units($theme-input-state-border-width);
    }
  }
  
  &--error {
    @include u-border($theme-input-state-border-width, "error-dark");
  }

  &--success {
    @include u-border($theme-input-state-border-width, "success");
  }

Compiles to:

.usa-input-group--error input:focus, 
.usa-input-group--success input:focus{
  outline-offset:0.25rem;
}

@amyleadem amyleadem left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good! I had a couple of comments for you — just some little things.

Comment thread packages/usa-input-prefix-suffix/src/styles/_usa-input-prefix-suffix.scss Outdated
Comment thread packages/uswds-core/src/styles/mixins/utilities/_disabled.scss
Comment on lines +27 to +32
&--error,
&--success {
& input:focus {
outline-offset: units($theme-input-state-border-width);
}
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the the outline-offset is a good consideration. Nice call.

Comment on lines +27 to +32
&--error,
&--success {
& input:focus {
outline-offset: units($theme-input-state-border-width);
}
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did notice that the input border (1px) is now covered by the focus outline, whereas it was visible before. It is a small thing, but just wanted to flag the visual difference. Not sure if it needs any action.

@mejiaj mejiaj left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mahoneycm some minor comments, otherwise LGTM.

Comment on lines +27 to +32
&--error,
&--success {
& input:focus {
outline-offset: units($theme-input-state-border-width);
}
}

@mejiaj mejiaj Feb 15, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, good consideration. I was initially put off by the level of nesting, but it makes sense. Moving forward we should be cautious with too much nesting.

Usually it's best practice to move your grouped selectors up before the individual ones. The & isn't necessary when it's a child element.

  &--error,
  &--success {
    // No need for the preceeding `&` here.
    input:focus { 
      outline-offset: units($theme-input-state-border-width);
    }
  }
  
  &--error {
    @include u-border($theme-input-state-border-width, "error-dark");
  }

  &--success {
    @include u-border($theme-input-state-border-width, "success");
  }

Compiles to:

.usa-input-group--error input:focus, 
.usa-input-group--success input:focus{
  outline-offset:0.25rem;
}

mahoneycm and others added 2 commits February 16, 2023 11:12
…suffix.scss

Co-authored-by: James Mejia <james.mejia@gsa.gov>
@mahoneycm mahoneycm requested a review from mejiaj February 16, 2023 16:27
@mahoneycm

Copy link
Copy Markdown
Contributor Author

@mejiaj Thanks for sharing! Always happy to have a method to the madness and organize our files.

I did some cleanup and pushed it up if you'd like to re review! Let me know if there's anything I can organize further!

@mahoneycm mahoneycm requested a review from amyleadem February 22, 2023 19:24

@mejiaj mejiaj left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thank you for your patience on this. Tested in Firefox, Chrome, and Safari.

Also, I went ahead and ran prettier sass task.


Odd, the original test failed in CircleCI due to a timeout. Wasn't able to reproduce locally and resolved on re-run.

@mahoneycm

Copy link
Copy Markdown
Contributor Author

Work implemented in #5063

@mahoneycm mahoneycm closed this Mar 29, 2023
@mejiaj mejiaj deleted the cm-prefix-suffix-disable branch July 18, 2023 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

USWDS - Bug: Prefix/suffix does not use disabled input styling

3 participants