Problem/Motivation
The link field in the Banner Block is white text on a pink background. This combination has a colour contrast ratio of 3.9:1.

The contrast ratio of 3.9:1 satisfies minimum contrast for WCAG 2.0 level AA, but note that it's in the special exception range for large-scale text. The link text is normal weight, and has a computed size of 19.2 CSS pixels. This doesn't meet the requirements for large-scale text, so this is a WCAG 2.0 failure.
This might be down to a confusion between points vs pixels. See this note from Understanding SC 1.4.3 Contrast (Minimum):
Note 1: When evaluating this success criterion, the font size in points should be obtained from the user agent or calculated on font metrics in the way that user agents do. Point sizes are based on the CSS pt size as defined in CSS3 Values. The ratio between sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt and 18pt are equivalent to approximately 18.5px and 24px.
Proposed resolution
Possible solutions, any of these will satisfy WCAG 2.0 SC 1.4.3 Contrast (minimum) for level AA conformance:
- Use
#D93760which was already on an old style guide (comment #9), and has ration 4.5:1 with white. PREFERRED: increase the colour contrast to 4.5:1, using a deeper shade of pink. Currently we are already at 3.9:1, so we might achieve 4.5:1 without drastically changing the the present colour palette. This approach is preferred because it's more flexible and re-usable; it passes without worrying about text size. Increase the font weight to 700 (bold), and confirm that all instances of this bg/fg colour combination have a computed size of at least 18.5 CSS pixels.Increase the font-size, to a computed size of at least 24 CSS pixels, and confirm that all instances of this bg/fg colour combination have a computed size of at least 24 CSS pixels.
Remaining tasks
Explore styles, especially a deeper pink which gets us to 4.5:1 contrast. Screenshots / mockups useful. Tip: treat the pink as a HSV color, and only adjust the -V part.
Patch.
Screenshots will be a useful confirmation, e.g. including evidence of computed font size form dev tools.
User interface changes
A small design change is required, whichever solution we use.
API changes
None.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 4.5-ratio-button_2938686-17.patch | 574 bytes | Adam_Moulsdale |
| #15 | lowercase-4.5-ratio-button_2938686-14.patch | 574 bytes | Adam_Moulsdale |
| #12 | after-2938686-11.png | 29.48 KB | andrewmacpherson |
| #12 | before-2938686-11.png | 39.34 KB | andrewmacpherson |
| #11 | 4.5-ratio-button_2938686-11.patch | 574 bytes | Adam_Moulsdale |
Comments
Comment #2
andrewmacpherson commentedComment #3
andrewmacpherson commentedSetting this to major status, we need to address this for our accessibility gate so it's a stability blocker.
Comment #4
andrewmacpherson commentedComment #5
andrewmacpherson commentedComment #6
andrewmacpherson commentedComment #7
Adam_MoulsdaleI have changed the background of this button to a deeper pink so that it now passes the AA standards (as shown).
Comment #8
andrewmacpherson commentedNice - thanks @Adam_Moulsdale!
The deeper pink #D1D46 has a contrast ratio of 4.8:1, which satisfies my accessibility head. Let's see what the design folk from the OOTB initiative team think.
These are the HSL equivalents, which show that the hue remains the same.
Before: #E84265 is HSL: 347° 78% 58%
After: #DD1D46 is HSL: 347° 77% 49%
Comment #9
andrewmacpherson commentedFeedback from @kjay in the OOTB slack channel....
Cool, white-on-#D93760 has 4.5:1 ratio so that satisfies the preferred approach too.
@Adam_Moulsdale - could you update the patch?
Comment #10
andrewmacpherson commentedComment #11
Adam_MoulsdaleI have updated the patch with #D93760 the 4.5:1 ratio.
Comment #12
andrewmacpherson commentedI confirmed this is the only instance of the colour in the Umami stylesheets.
Some screenshots for reference. The design impact is negligible, but it gets us over the line for WCAG contrast.
Before patch #7:
After patch #7:

Comment #14
andrewmacpherson commentedOur CSS formatting guidelines say colour hex codes should use lower-case. That's why the patch fails to apply.
Comment #15
Adam_MoulsdaleI followed suit as the original code was lower case.
Updated.
Comment #17
Adam_MoulsdaleRookie mistake, didn't have the latest version on Core as I was doing the patch.
4th time lucky.
Comment #18
markconroy commentedThanks @adam_moulsdale.
Tested during our weekly call today.
Comment #19
catchLooks like an oversight rather than a design decision, so I've gone ahead and committed/pushed to 8.6.x, thanks!