Color scheme generator picks the button contrast colour with a brightness threshold, so mid-luminance brand colours get white text below WCAG AA

[Justinvolved]

Describe the bug

When a colour scheme is saved, ColorSchemeHelper writes --dw-color-button-primary-contrast and --dw-color-button-secondary-contrast from Dynamicweb.Imaging.Colors.Color.GetContrastColor(). That method computes a weighted brightness (R*0.299 + G*0.587 + B*0.114) and returns #fff when 255 - brightness >= 105, otherwise #000. It does not compare contrast ratios. Amber, orange and mid-green brand colours land on the white side even though white text on them fails WCAG 2.x AA (4.5:1), while black text passes easily. Swift buttons then render white labels that are hard to read.

To Reproduce

1. Save a colour scheme with primary button colour #B8860B and secondary button colour #2E9E44 (admin UI or MCP save_color_schemes).
2. Open the generated Files/System/Styles/ColorSchemes/<group>.css.

Observed (DW 10.28.11):

--dw-color-button-primary: #B8860B;
--dw-color-button-primary-contrast: #fff;
--dw-color-button-secondary: #2E9E44;
--dw-color-button-secondary-contrast: #fff;

Contrast ratios (WCAG 2.x relative luminance):

fill	generated ink	white on fill	black on fill
#B8860B	#fff	3.25:1 (fails AA)	6.45:1
#E07B00	#fff	3.00:1 (fails AA)	7.00:1
#2E9E44	#fff	3.45:1 (fails AA)	6.09:1

Source (Dynamicweb.Core 10.28.11, decompiled):

public string GetContrastColor()
{
    int num = 105;
    int num2 = Convert.ToInt32(BaseColor.R * 0.299 + BaseColor.G * 0.587 + BaseColor.B * 0.114);
    if (255 - num2 >= num) return "#fff";
    return "#000";
}

Expected behavior

The contrast colour is the one with the higher WCAG contrast ratio against the fill: compute the relative luminance, compare (L1 + 0.05) / (L2 + 0.05) for white and for black, and pick the larger. Optionally, the scheme editor lets the user override the generated contrast colour per button colour.

Environment

• Dynamicweb 10.28.11 (.NET 10 hosting), Swift 2.4