Skip to content

Form Inputs: Normalize disabled forms styles #5063

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

Merged
merged 176 commits into from
May 17, 2023
Merged

Conversation

mahoneycm
Copy link
Contributor

@mahoneycm mahoneycm commented Dec 6, 2022

Preview →

Resolves #5051
Includes work from:
#5004
#5128
#5146

Description

Creates and normalizes disabled styles across USWDS forms.

Breaking change

⚠️ This is potentially a breaking change.

Existing usa-combo-box, usa-date-picker, usa-file-input components with aria-disabled="true" may be affected now that the javascript for each component looks for that attribute during initialization

While we advise against using the usa-button--disabled class, this would break markdown for devs who have implemented it

Related PRs

USWDS Site change log PR →

The Problem

Currently, Chrome and Edge support disabled styles for forms. Both implement a pretty minimal opacity shift to disabled elements to help users understand an element is disabled. The shift is pretty minor:

Enabled vs disabled in Chrome
Screen Shot 2022-12-08 at 12 46 27 PM

Safari & Firefox do not offer any visual queues an element is disabled at this time. This can cause

The solution

Create USWDS styles for disabled forms to add visual context for users.

Text Input Disabled
image

Affected components

All components within the Forms Inputs category on Storybook as well as Button

Updates made

  • All form controls and buttons have matching disabled and aria-disabled states
    • Every disabled element and its overlaid text meets WCAG AA contrast:
      • Disabled backgrounds are defined with $theme-color-disabled ("gray-20")
      • Text on default backgrounds are defined with the new variable: $theme-color-disabled-text (”gray-50”)
      • Text on reverse backgrounds are defined with the new variable: $theme-color-disabled-text-reverse ("gray-40")
      • Text on disabled backgrounds are defined with the new variable: $theme-color-text-on-disabled ("gray-70")
    • Disabled styles now receive cursor: not-allowed
    • Disabled styles do not show hover states
    • Removed all disabled classes (This only applies to user-added disabled styles. Dynamically-added styles are still allowed)
    • Dynamically-added disabled styles are triggered for both disabled and aria-disabled
  • All disabled states are consistently demonstrated in Storybook
    • A new Disabled Forms story has been added that shows all disabled form elements on one page
    • All disabled/aria-disabled controls in storybook are consistent
    • For buttons, aria-disabled is now included in the “show all states” control, which is displayed by default
  • Input prefix/suffix: removed need for a disabled class
    • The CSS was re-written to absolutely position the icons instead of relying on disabled parent class
    • Removed index.js and related test files because they were no longer needed (the JS moved focus to the disabled group, which no longer exists
  • Removed test pattern twig for usa-select—multiple; can rely on standard twig instead

New disabled utility mixin

The new u-disabled mixin overrides background-color and cursor styles of elements to display as disabled. Includes overrides for hover, active, and focus states.

Users can pass in $bg-color & $text-color parameters as necessary to add custom colors if needed.

An example of this can be found for usa-button--outline variants to ensure color compliance

@include u-disabled("transparent", $theme-color-disabled-text);

New Disabled Color Tokens

Token Name Color
$theme-color-disabled-text "gray-50"
$theme-color-disabled-text-reverse "gray-40"
$theme-color-text-on-disabled "gray-70"

Preview

Disabled Forms →

To Test

  • Visit each of the form components
  • View disabled variant or turn on disabled and/or aria-disabled
  • You may need to refreseh the page in order for the components javascript to initialize and the view to update
  • Confirm:
    • disabled elements have a grey background and a not-allowed cursor on hover
    • aria-disabled styles mimic disabled styles (Components will still be accessible if not disabled)
    • Both style work together and add relative attribute to html code

Notes & Other Considerations

After discussion, we have decided to allow disabled classes that style elements that:

  • Do not receive the disabled attribute
  • Are dynamically placed
    This will allow us to correctly style elements as disabled without putting the burden on the user.

Further findings from my disabled landscape analysis can be found at #5117

⚠️ We should consider adding new disabled tokens to theme color tokens and create a page for the disabled utility mixin in Utilities

Moving forward, we should also create guidance on our website about accessibility and disabled form elements to assist users in understanding when it is and is not appropriate to use these new styles and mixin

Before you hit Submit, make sure you’ve done whichever of these applies to you:

  • Follow the 18F Front End Coding Style Guide and Accessibility Guide.
  • Run npm test and make sure the tests for the files you have changed have passed.
  • Run your code through HTML_CodeSniffer and make sure it’s error free.
  • Title your pull request using this format: [Website] - [UI component]: Brief statement describing what this pull request solves.

@mahoneycm mahoneycm requested review from amyleadem and mejiaj December 8, 2022 19:53
@mahoneycm mahoneycm marked this pull request as ready for review December 14, 2022 14:54
@mahoneycm mahoneycm requested review from amyleadem and mejiaj April 3, 2023 16:58
Copy link
Contributor

@mejiaj mejiaj left a comment

Choose a reason for hiding this comment

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

Double-checked the button and button group styles. No issues found!

Copy link
Contributor

@amyleadem amyleadem left a comment

Choose a reason for hiding this comment

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

All changes since my last approval look good!

Copy link
Contributor

@thisisdano thisisdano left a comment

Choose a reason for hiding this comment

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

@mejiaj Had a couple observations that are worth addressing, especially the Combo box issue

&:disabled,
&[aria-disabled="true"] {
@include u-disabled;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

@mahoneycm I think we need to address this

@@ -147,6 +158,11 @@ const buildFileInput = (fileInputEl) => {
disable(fileInputEl);
}

// Aria-disabled styling
if (ariaDisabled) {
ariaDisable(fileInputEl);
Copy link
Contributor

Choose a reason for hiding this comment

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

@mahoneycm We should probably fix this too, if it looks like a simple fix, even though I'd guess this is more of an edge case, having an error state on a disabled element

Copy link
Contributor

@thisisdano thisisdano left a comment

Choose a reason for hiding this comment

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

My comments above came from an incomplete and incorrect understanding of aria-disabled — which is, by design, responsible only for conveying disabled state to screen reader. See this MDN documentation.

Since this PR is about normalizing styles and not about JS, I think we can ignore my comments above and proceed.

@thisisdano thisisdano merged commit 70f6c0d into develop May 17, 2023
@thisisdano thisisdano deleted the cm-disabled-forms-styles branch May 17, 2023 22:05
@thisisdano thisisdano mentioned this pull request Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants