fix(a11y): disabled button behavior and color contrast #65

huyenltnguyen · 2024-04-10T08:16:52Z

Checklist:

I have read freeCodeCamp's contribution guidelines.
My pull request has a descriptive title (not a vague title like Update index.md)

Issues and Context

There are two issues with the Button component, which were brought up in freeCodeCamp/freeCodeCamp#53824 (comment):

Button with type="submit" can still trigger form submission even if it's disabled
The text of disabled button doesn't have sufficient contrast

(1) is indeed a bug and the fix is straight forward, so I only want to discuss (2).

So if we want to reflect the disabled state of an element, we can use either the HTML disabled or aria-disabled attribute.

With the disabled attribute, the element is still present in the DOM, but removed from the accessibility tree, meaning non-sighted users won't know the button is there nor its disabled state, and they also can't interact with it.

With the aria-disabled attribute, the users can use the keyboard to focus on the button, and can be informed about the element and its disabled state. This is the behavior I decided to go with, as the UX is much better.

However, we have been dimming the text and background color of the button is communicate the disabled state visually. This would be acceptable if the button isn't interactable, but since we want it to be interactable, we are failing the color contrast requirement.

Approaches

To address the color contrast requirement, the most straightforward fix would be improving the contrast. We are currently using the opacity attribute to dim the colors, but in order to make the button look nice and accessible, we would need to play with the color combinations and not just cranking up the opacity. We also don't have colors that could be used for the disabled state of the danger and info variants, so I'd need some help here (from Ahmad) if we want to proceed with the color update.

Alternatively, I think we should consider removing the disabled state and keeping buttons enabled at all time.

If the user isn't allowed to perform an action, we can completely hide the button.
If the user can only perform an action if they have fulfilled all the requirements, we can add a validation check to the button, and show a message telling the user what they have missed, or complete the action if the requirements are met.

That would help resolve the color contrast and interactivity issues, while also improving the user experience. (I think we've been assuming the users would understand why the button is disabled and how to enable it, but that might not be obvious for some).

My Fix

I might have gone a little overboard with the changes.

My fix is a mix of both approaches:

I updated the CSS of the disabled state of the primary button to improve the contrast
I set the disabled value of the danger and info to always false

Rationale:

I checked /learn's global.css stylesheet and found that all buttons have primary styles when they are disabled (notice the button selector and the colors used in the code), so I assume we implicitly don't support disabled state in danger and info variants (otherwise they look very different from their enabled state).
In /learn, there isn't any danger or info button that is used with the disabled prop (meaning danger and info buttons are enabled at all time).

The changes are to close down the feature that has no usages, and to move us closer to the second approach above (assuming everyone agrees with the approach).

Screenshots

Basically instead of dimming the text and the background colors, I dim the border color to communicate the disabled state.

	Before	After
Light
Dark

…sabled-button

huyenltnguyen · 2024-04-15T06:58:51Z

src/button/button.stories.tsx

It's much easier to review the changes if you review by commit.

huyenltnguyen · 2024-04-15T07:37:16Z

src/button/button.stories.tsx

@@ -115,4 +119,37 @@ export const AsADownloadLink: Story = {
 	},
 };

+const FormWithSubmitButton = () => {


Added a story to demonstrate the usage of Buttons in a form.

huyenltnguyen · 2024-04-15T07:38:55Z

src/button/button.tsx

@@ -133,6 +127,7 @@ const StylessButton = React.forwardRef<React.ElementRef<"button">, ButtonProps>(
 		// Ref: https://css-tricks.com/making-disabled-buttons-more-inclusive/#aa-the-difference-between-disabled-and-aria-disabled
 		const handleClick = (event: React.MouseEvent<HTMLButtonElement>) => {
 			if (disabled) {
+				event.preventDefault();


This is the one-liner to fix the submission issue.

huyenltnguyen · 2024-04-15T08:00:29Z

src/button/button.test.tsx

+// Type tests
+// ------------------------------
+
+// @ts-expect-error - Button with `danger` variant cannot be disabled


So with the proposed change to the danger and info variant, we will get a TS error if disabled is true on these variants.

I'm writing tests for the changes using // @ts-expect-error, which:

Expects the provided code to throw an error, but suppresses the error

Throws an error if the provided code doesn't have any type check errors

huyenltnguyen · 2024-04-15T08:01:21Z

src/button/button.tsx

-	// Disabled state
-	"aria-disabled:cursor-not-allowed",
-	"aria-disabled:opacity-50",


Moved the disabled styles to the primary variant, instead of leaving it in the base/default class list.

huyenltnguyen · 2024-04-15T08:01:51Z

src/button/button.tsx

@@ -54,48 +51,45 @@ const computeClassNames = ({
 				"border-foreground-danger",
 				"bg-background-danger",
 				"text-foreground-danger",
-				...(disabled


Removed disabled styles from the danger variant.

huyenltnguyen · 2024-04-15T08:25:00Z

src/button/button.tsx

 			);
 			break;
 		case "info":
 			classNames.push(
 				"border-foreground-info",
 				"bg-background-info",
 				"text-foreground-info",
-				...(disabled


Removed disabled styles from the info variant.

huyenltnguyen · 2024-04-15T08:28:03Z

src/button/types.ts

@@ -4,16 +4,34 @@ export type ButtonVariant = "primary" | "danger" | "info";

 export type ButtonSize = "small" | "medium" | "large";

-export interface ButtonProps
+interface BaseButtonProps


Reorganized the props so that we can enforce stricter type checking.

As proposed, only the primary variant can have disabled being true.

ahmaxed · 2024-04-22T13:56:43Z

We could go with the current colors and discuss adding more in the redesign.

huyenltnguyen added 2 commits April 11, 2024 12:56

fix: disabled submit button triggers form submission

12c5ba3

fix: color contrast of disabled state

a972159

huyenltnguyen force-pushed the fix/disabled-button branch from 083bae2 to a972159 Compare April 11, 2024 06:14

Merge branch 'main' of https://github.com/freeCodeCamp/ui into fix/di…

339ade3

…sabled-button

huyenltnguyen commented Apr 15, 2024

View reviewed changes

huyenltnguyen assigned ahmaxed Apr 15, 2024

huyenltnguyen marked this pull request as ready for review April 15, 2024 08:29

huyenltnguyen requested a review from a team as a code owner April 15, 2024 08:29

ahmaxed approved these changes Apr 22, 2024

View reviewed changes

ahmaxed merged commit 4d0cc6f into freeCodeCamp:main Apr 22, 2024
4 checks passed

huyenltnguyen deleted the fix/disabled-button branch April 24, 2024 04:22

huyenltnguyen mentioned this pull request May 23, 2024

fix(a11y): disabled button color contrast freeCodeCamp/freeCodeCamp#54248

Merged

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(a11y): disabled button behavior and color contrast #65

fix(a11y): disabled button behavior and color contrast #65

huyenltnguyen commented Apr 10, 2024 •

edited

Loading

huyenltnguyen Apr 15, 2024

huyenltnguyen Apr 15, 2024

huyenltnguyen Apr 15, 2024

huyenltnguyen Apr 15, 2024

huyenltnguyen Apr 15, 2024

huyenltnguyen Apr 15, 2024

huyenltnguyen Apr 15, 2024

huyenltnguyen Apr 15, 2024

ahmaxed commented Apr 22, 2024

fix(a11y): disabled button behavior and color contrast #65

fix(a11y): disabled button behavior and color contrast #65

Conversation

huyenltnguyen commented Apr 10, 2024 • edited Loading

Issues and Context

Approaches

My Fix

Screenshots

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahmaxed commented Apr 22, 2024

huyenltnguyen commented Apr 10, 2024 •

edited

Loading