[2.x] Colour Contrast Checker

[hiddenenigma]

Increasing access

Contrast is a key design principle for making elements distinguishable from one another. If there's low contrast between colors, no one will see the sketch. The proposal is to have a color contrast checker to see if it passes the double AA and triple AAA accessibility standards.

This tool is a good example where the user can input their colors and adjust using sliders until their colors meet the accessibility pass: https://colourcontrast.cc/

Which types of changes would be made?

• Breaking change (Add-on libraries or sketches will work differently even if their code stays the same.)
• Systemic change (Many features or contributor workflows will be affected.)
• Overdue change (Modifications will be made that have been desirable for a long time.)
• Unsure (The community can help to determine the type of change.)

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

What's the problem?

Currently there's no way for users to know if their colors are accessible. Meaning, if there's low contrast with their colors.

What's the solution?

A color contrast checker that checks for different accessibility passes.

Pros (updated based on community comments)

Example list:

• Consistency: This proposal increases API consistency by...
• Readability: This proposal makes the source code more readable by...
• Other advantages...

Cons (updated based on community comments)

Might be difficult to implement when there are multiple colors and it's an animation where colors overlap with each other at different times.

Proposal status

Under review

[limzykenneth]

I wonder if this can be expanded into a wider accessibility checker feature that can form part of the Web Accessibility module of p5.js? Eg. also adding a function that when passed a HTML container element, check everything inside it for adherene to best practices of web accessibilty/WCAG recommendations?

[ksen0]

Hi @calebfoss , this is the issue you meant in your recent comment, right? (Please feel free to transfer this conversation elsewhere if I misunderstood.)

You said:

The color contrast method would be a particularly easy addition. I could put together a PR for that in a matter of a few days if you're interested.

What's the proposed API / learner experience here? If this a function call that gives info to be displayed, and/or is it something in FES? If we agree to the minimal first version of this feature, happy to proceed with implementation for a minor release of 2.x.

Three considerations, please feel free to expand/amend from your understanding/experience:

1. A learner should be able to use this function to understand when their sketch passes/fails. If their sketch involves changing colors, they should be able to understand when it's ok and when not.
2. A teacher should be able to help student(s) quickly recover from color contract issues. I'm not sure what this could look like, but I'm reminded of colorbrewer map color scales and the vega color scales - information visualization make it very easy to use color scales that have been determined to be legible and informative. How can the color contrast checker most efficiently suggest recovery?
3. A (future) contributor should, as @limzykenneth suggested above, be able to extend this. For example if this is an API call, can it be general enough to be used for other checks? Eg, the way textProperty takes key/value pairs and can be extended in that way. For example: future features for checking if describe is used; if there is strobing effects; WCAG recommendation adherence. For example: require describe() function in p5 sketches? #5427

The first version of this feature can focus on just the learner experience but the design of the technical approach should be mindful of the other two - but of course the actual details of those 2 are open for discussion as well!

[calebfoss]

@ksen0 There isn't a direct pairing between all the changes I proposed in #6992 and other issues. Would you like me to create a new issue for each part of #6992 and copy/paste what I wrote? I did reference this issue in #6992 but suggested a slightly different approach. I'll copy over my proposal, my update from #7488, and a couple additional new thoughts and responses to your comment.

From #6992

Issue #6971 proposes a way to check whether the contrast between colors in a sketch is meeting WCAG AA or AAA.

I drafted a method to calculate contrast based on WebAIM's tool. When passed two p5.Color's, it returns the contrast ratio between them: https://editor.p5js.org/cfoss/sketches/-okUAfg7Z

Note that this does not currently account for alpha level or blend mode, and it would need to do that for accuracy.

This could be modified to check for specific AA and AAA target ratios. I would argue, though, that this information would be better placed in the reference, where it could be linked, contextualized, and updated without modifying the function itself.

@limzykenneth responded

I wonder if this can be expanded into a wider accessibility checker feature that can form part of the Web Accessibility module of p5.js? Eg. also adding a function that when passed a HTML container element, check everything inside it for adherene to best practices of web accessibilty/WCAG recommendations?

While I think a broader accessibility checker is an exciting idea, I believe that implementing it such that it reliably gives accurate results would be a daunting task.

I am not aware of a way to check what default styles a browser has applied to an element beyond the styles set via CSS, style property, etc. On top of that, accounting for all the possible factors that would influence which element appears on top of which would be very challenging.

For those reasons, when it comes to color contrast at least, I do not think automatically checking elements is a realistic goal.

I could imagine an automatic checker for semantic structure: checking for more than one h1, mismatching h1 and title, disorganized heading levels, etc. Having a button in the p5 editor that opens such a checker would be great.

From #7488

#6992 includes a sketch I put together in the p5 editor as a proof of concept for a function that calculates contrast between colors to help p5 creators meet WCAG SC 1.4.6. Since v2 already includes changes to the p5.Color class, I think the contrast calculator would make a great addition to the class as well. You could include both a static and instance method, similar to p5.Vector methods:

let colorA = color(255, 0, 0);
let colorB = color(0, 255, 0);

// These would return the same value
let contrastBetween = colorA.contrast(colorB)
contrastBetween = p5.Color.contrast(colorA, colorB);

New thoughts

Correction on my initial proposal: There actually is a way to check styles applied by the current browser with getComputedStyle(). That doesn't solve the overall problem I brought up, though. Browsers do not necessarily use the same default colors, and figuring out which elements are on top of which would be a super tricky puzzle.

@ksen0 regarding your questions, my proposal is to return the contrast ratio value as a number (as demoed in my proof of concept). This allows for a ton of flexibility in terms of usage for learners, teachers, and creators in general.

I just created an example of how a creator could use this method to switch backgrounds for user-selected text color: https://editor.p5js.org/cfoss/sketches/wBQ_41UWy

[ksen0]

Hi @calebfoss thanks so much for the clarifications and context, I agree with your comments on scope.

let colorA = color(255, 0, 0);
let colorB = color(0, 255, 0);

// These would all return the same value
let contrastBetween = colorA.contrast(colorB)
contrastBetween = p5.Color.contrast(colorA, colorB);
contrastBetween = p5.Color.contrast(colorB, colorA);
contrastBetween = colorB.contrast(colorA);

Please feel free to go ahead and implement this in the Color class - or comment / mark this as help wanted if you prefer to open it to other contributors. EDIT: Would be great if docs for this function mention the webaim color contrast checker you linked and the theoretical min and max, I think it's a great teaching moment to use the same scale for contrast but I would expect the numeric value range to be surprising.

I think it would be good for the PR for this to include in unit tests for every color mode to prevent regressions (even if at the moment no adjustments for color modes are needed). The tests could be part of implementation or a separate "Good First Issue" task (I think lots of unit tests are Good First Issues, in this case the p5.Color and calculation seem especially approachable, unless there's complexity I'm not seeing!)

Would you like me to create a new issue for each part of #6992 and copy/paste what I wrote? I did reference this issue in #6992 but suggested a slightly different approach.

Yes I think splitting these up would be very helpful to move them along, I'm writing a comment over there about it.

[calebfoss]

@ksen0 - Sounds good thanks! I went ahead and added the Help Wanted label. I'd love to help on this, but now in the last few weeks of the academic year, I realistically do not expect to be able to give this the attention it needs for a while. So if someone else is ready to step in, please do! I can share feedback on the PR if nothing else.