Change the textcolor passed to ContrastChecker

[Jackie6]

Description

Fix #14687

How has this been tested?

• Local
• Browser testing

Types of changes

Change the parameters passed to ContrastChecker so that the contrast warning works correctly. That is only when we see light text on light background or dark text on dark background, the warning will be displayed.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[gziolo]

@jorgefilipecosta - can you double check the solution proposed?

[gziolo]

Black is encoded as #000.

[Jackie6]

Hi, @gziolo Thanks for your comments. I inspect the CSS files.
When I set the background color to primary, secondary, light gray, dark gray, the CSS file is

so the color is '#fff' (white)

When I set the background color to white, the CSS file is

so the color is '#111' (black)

And you are right, '#000' is also black. But to maintain the consistency, '#111' may be better I think.

[gziolo]

Upon inspection of the file, it seems like it might be necessary to provide defaults inside the implementation of withFallbackStyles at the top of the file in place of undefined values.

[jorgefilipecosta]

Hi @Jackie6, @gziolo the root cause of the bug was that withFallbackStyles never recomputed fall back styles again after all fall back styles were known.
This assumed that fallBack colors of specific block instance (colors set with CSS) never changed during the editor execution. This assumption was wrong.
When we set a background color dark in twenty nineteen the CSS class also sets a text color (the text color attribute is not changed), so in this case setting a background color changes the fallback text color.
I proposed an alternative fix for the original bug in #14963 that allows users of withFallbackStyles to have more control over when the fall back styles should be recomputed again.

[gziolo]

I proposed an alternative fix for the original bug in #14963 that allows users of withFallbackStyles to have more control over when the fall back styles should be recomputed again.

Does it mean we should close this PR and help land the alternative fix?

[jorgefilipecosta]

Does it mean we should close this PR and help land the alternative fix?

I guess that would be the best approach as the solution #14963 is more general while this one more specific to a set of colors used by some themes but may not work in every theme.

[gziolo]

@Jackie6 thanks for working on this PR, let's fly with the proposal from @jorgefilipecosta as it looks more complicated than it seemed on the surface.