Improve Disabled color palette and make it more readable...

[apsthisdev]

Evaluating the default color palette for fast template and found out that the disabled palette color for light and dark mode should be improved. The current palette generation algorithm generates the neutral disabled colors that are too light and makes is difficult for users to read.

See samples, the black mode is probably OK but the disabled foreground color for Light and Dark model could definitely use a shade darker/brighter.

Black Mode (Layer Luminance 0)

Light Mode (Layer Luminance 1)

Dark Mode (Layer Luminance 0.23)

Issue Both the Light and Dark Mode results in the disability colors ID and Name test fields that are not intuitive. It is difficult for user to make out especially if there are large number of disabled fields.

[chrisdholt]

Pinging @bheston who can provide some insight on how the color values are calculated, etc. As a note, the default behavior of recipes is to ensure WCAG2.1 AA color contrast requirements are met. For disabled controls, I do not believe there is any minimum contrast requirements, so this is technically by design.

With that said, we expose a design token for the disabled opacity value which can be set in v1 through the design system provider. In vNext you'll be able to configure the design system with a different token value as well.

[apsthisdev]

@chrisdholt, thanks for the pointer. The disabled opacity does help improve the readability of disabled fields.

    //  Adjust the disabled opacity.
    designSystemProvider.disabledOpacity = "0.5";

[chrisdholt]

@chrisdholt, thanks for the pointer. The disabled opacity does help improve the readability of disabled fields.

    //  Adjust the disabled opacity.
    designSystemProvider.disabledOpacity = "0.5";

Awesome, if this resolves your issue can we close this? Glad it got worked out quickly :)

[apsthisdev]

Yeah good to go from my side. Some documentation update may be useful for others !

[bheston]

Yeah, as Chris mentioned the accessibility spec does not require any contrast ratio for disabled controls (pressed/active state either). The thought is that if a control is disabled you can't interact with it so it's not important to always be able to read it. The challenge you might face by increasing the opacity of the disabled control is that it will look enabled, instead causing frustration by being able to clearly read something but not interact with it. We also apply the disabled cursor which helps with this, but from a glanceability standpoint this may still be an issue.

If you're using any hint text, check to make sure you can tell the difference between hint text and disabled text. Hint is not calculated using opacity, but I feel like the current value probably comes in very close to 50%.

[apsthisdev]

Thanks. How do I know what disabled opacity factors are used for various neutral colors? Also, is there any documentation to refer to before apps customize the opacity factor so that the colors does not overlap ?

[chrisdholt]

Thanks. How do I know what disabled opacity factors are used for various neutral colors? Also, is there any documentation to refer to before apps customize the opacity factor so that the colors does not overlap ?

Sorry to see this go stale - hopefully you were able to find your answer! If not, disabled opacity is set via the Design System and with a token value in the current version. This ensures a consistent application across all instances. In terms of overlapping color, I think the closer you get to 50% and above the more likely you are to have issues discerning between disabled and non-disabled controls. I'd probably advise going no more than 50% simply due to how difficult it can be to tell if something is intentionally opaque and enabled or "disabled".