search

alphagov / govuk-frontend

GOV.UK Frontend contains the code you need to start building a user interface for government platforms and services.
https://frontend.design-system.service.gov.uk/
MIT License
1.17k stars 321 forks source link

Consider testing our colour styles against the APCA contrast method #4066

Open dav-idc opened 1 year ago

dav-idc commented 1 year ago

What

We have a set of 'colour' styles within our design system, which were tested for colour contrast agains the WCAG 2.x colour contrast method.

Our two sets of colour styles are:

Consider testing these colours against the APCA method. APCA is being explored as a potential successor contrast method for WCAG 3, but the testing tools are available now.

What it would involve

Using the Bridge-PCA testing tool, test our colour contrasts against both the WCAG 2.x method and APCA.

Documentation

Why

The APCA method is evidenced to do a more consistent job at matching real-world contrast needs. There's still no settled consensus on APCA's advantages and disadvantages as a tool for measuring contrast, but I figure it's probably a good enhancement to our colours.

Measuring against both methods will:

Who needs to work on this

Developers, interaction designers, accessibility specialist

Who needs to review this

Done when

querkmachine commented 1 year ago

Some quick tests with the above tool on some common components and patterns.

Notably, the tool seems to make the distinction on whether the colour is used in the foreground or background, which the current WCAG criterion doesn't do.

Example Text color Background colour PCA PCA (WCAG compatible) WCAG
Body text #0b0c0c #ffffff 105.8 15.8 19.6
Body links #1d70b8 #ffffff 75.1 4.6 5.2
Header #ffffff #0b0c0c -105.0 15.3 19.6
Footer — Seconday buttons — Tabs #0b0c0c #f3f2f1 98.1 11.6 17.5
DS site main navigation #1d70b8 #f8f8f8 71.0 ⚠️ 4.2 4.9
DS site masthead — Notification banner #ffffff #1d70b8 -77.8 5.1 5.2
Link focus style — Skip link #0b0c0c #ffdd00 86.6 7.5 14.5
Default buttons — Panel — Successful notification banner #ffffff #005a30 -90.3 8.2 8.4
Warning buttons #ffffff #d4351c -74.9 4.6 4.9
Error messages #d4351c #ffffff 72.1 ⚠️ 4.2 4.9

Initial thoughts takeaways:

dav-idc commented 1 year ago

@querkmachine thanks for taking a peek! I've started a spreadsheet to compile all the values, if working from there is comfortable for you. I've set it to be publicly commentable. https://docs.google.com/spreadsheets/d/17-LEU0x5UyZbXJ66d0dR6-SQXTuPosFlLN8-3qygw-E/edit?usp=sharing

dav-idc commented 1 year ago

I'm also noting that your colour combos in that table above are definitely more real-world applicable than my method of testing everything with white and black. I think your method of curating text and background colours makes sense to me, especially for the 'main' colours.

For the colour palette (like the pink, orange and teal), perhaps that's where the contrasts with black or white come in handy.

querkmachine commented 1 year ago

Copied across and fleshed it out with more tests. 👍

Myndex commented 1 year ago

Hi @querkmachine and @davidc-gds

I happened upon your thread here, and as I'm the creator of APCA and BPCA I wanted to chime in and provide some additional information if you'd like. Some of this is from a FAQ I'm working on.

...Pretty much universally the perceived contrast under PCA is less than the current WCAG calculation, drastically so in the case of link focus and the footer....

The calculated contrast is lower, this means the actual perceived contrast will be higher. Here are three related FAQ QAs if you want a deeper dive:

.

1) How is BridgePCA different than WCAG 2.x contrast? BridgePCA uses a completely different algorithm to calculate the contrast value. BridgePCA is based somewhat on the APCA math, but BridgePCA has some offsets to ensure backwards compatibility. What backwards compatibility means in this case is that if WCAG 2.x fails a color pair, then BridgePCA will as well. However, WCAG 2.x has been shown to a;;ow for color pairs that are not particularly accessible—in some independent studies, 47% or more pairs that passed should have been rejected. Bridge PCA rejects these poor quality color pairs.

.

2) How is BridgePCA different than APCA Readability Criterion? BridgePCA is designed to work with the existing WCAG 2 SCs, particularly 1.4.3. In order to ensure backwards compatibility, it rejects some color pairs that APCA allows. APCA is a perceptually uniform method across the visual range, and is better at determining luminance contrast (lightness/darkness), the key contrast for reading. This includes for color vision deficiencies (CVD). WCAG 2.x is incorrect in certain ways regarding color vision issues because it allows some colors that should fail (47%) and paradoxically rejects some colors that should pass (22%). The colors WCAG2 wrongly passes can be bad for CVD (or all users quite frankly), and the _related_ colors it wrongly fails would have been much better for CVD. This is why the full APCA is not backwards compatible. Bridge PCA is simply a modification to allow backwards compatibility by throwing away some useful colors.

.

3) Why is Bridge PCA's ratio lower than WCAG 2? The current iteration of Bridge PCA maintain's APCA's _polarity sensitivity_. This means it calculates differently for light mode and dark mode. And dark mode can calculate 10% or higher than the same pair of colors for light mode. As a result, dark mode is the mode that is aligned to WCAG 2. And because WCAG 2 is not polarity sensitive, in light mode the ratio will be 10% or more lower.

.

Something under consideration

...Colours considered acceptable in one configuration are not in another (e.g. warning button vs. error message)...

Considering removing polarity (light/dark mode) from Bridge (click 4 more) And I'd love to hear your opinions on the following. As mentioned under #3 above, BridgePCA is sensitive to the difference of light and dark modes polarities, while WCAG 2 is not. This results in BridgePCA forcing some higher contrasts than _perhaps_ needed in some cases. Since WCAG 2 does not handle polarity, and BridgePCA is really only a temporary "bridge" for WCAG2 until APCA is adopted in law more widely, it occurs to me that we could usefully simplify by making BridgePCA disregard which input is text or BG. In essence, we'd use the light-mode value for both, and then re-align light mode to be closer to WCAG when one of the colors was white or very light. I'm thinking this would help eliminate some confusion, and make things easier to use which is really a big part of this. This should not impact forward compatibility, as dark mode is generally more liberal in terms of contrast value.

.

WCAG Alignment

The following is also covered more in FAQ #1 & #2 above.

...The possible threshold generally seems to be lower. Pure black on pure white in WCAG is the highest possible contrast ratio of 21:1, in WCAG compatible PCA the same combination is 16:1....

Bridge follows WCAG only as needed (click 4 more) Once Bridge PCA is above 7:1, it is no longer trying to align to the WCAG 2 slope at all, largely because the alignment is synthetic in the first place, to force backwards compatibility. Essentially, when the text color is white, then BridgePCA is calculating dark mode, and will track WCAG 2 fairly closely through the range of 3:1 thru 7:1. Outside of that range is less relevant, as there are no WCAG 2 thresholds in that range.

Please let me know if you have any questions, either direct, here in this thread, or in the APCA forum.

ALSO: You may be interested in the APCA Readability Criterion, while a work in progress, the main text guidelines and the Bronze Simple Mode are fairly complete and have been testing across many sites with good results. And the APCA-RC shows the general direction, and hints for the future.

Thank you for reading.