-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Conversation
…o cm-disabled-forms-styles
…o other components

There was a problem hiding this 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!

There was a problem hiding this 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!
There was a problem hiding this 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; | ||
} |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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
There was a problem hiding this 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.
Preview →
Resolves #5051
Includes work from:
#5004
#5128
#5146
Description
Creates and normalizes disabled styles across USWDS forms.
Breaking change
Existing
usa-combo-box
,usa-date-picker
,usa-file-input
components witharia-disabled="true"
may be affected now that the javascript for each component looks for that attribute during initializationWhile 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

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

Affected components
All components within the
Forms Inputs
category on Storybook as well as ButtonUpdates made
disabled
andaria-disabled
states$theme-color-disabled
("gray-20")$theme-color-disabled-text
(”gray-50”)$theme-color-disabled-text-reverse
("gray-40")$theme-color-text-on-disabled
("gray-70")cursor: not-allowed
disabled
andaria-disabled
Disabled Forms
story has been added that shows all disabled form elements on one pagedisabled
/aria-disabled
controls in storybook are consistentaria-disabled
is now included in the “show all states” control, which is displayed by defaultindex.js
and related test files because they were no longer needed (the JS moved focus to the disabled group, which no longer existsusa-select—multiple
; can rely on standard twig insteadNew
disabled
utility mixinThe new
u-disabled
mixin overridesbackground-color
and cursor styles of elements to display as disabled. Includes overrides forhover
,active
, andfocus
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 complianceNew Disabled Color Tokens
$theme-color-disabled-text
$theme-color-disabled-text-reverse
$theme-color-text-on-disabled
Preview
Disabled Forms →
To Test
disabled
and/oraria-disabled
disabled
elements have a grey background and anot-allowed
cursor on hoveraria-disabled
styles mimicdisabled styles
(Components will still be accessible if notdisabled
)Notes & Other Considerations
After discussion, we have decided to allow disabled classes that style elements that:
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
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:
npm test
and make sure the tests for the files you have changed have passed.