WCAG 2.3.2 - Flashing light check

[calebfoss]

Increasing access

This feature would help p5 creators to follow WCAG 2.3.2, making their creations more accessible and safer.

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)

Feature request details

This is a sub-issue of #6992

From #6992

WCAG 2.3.2 specifies limits on flashing light.

I would propose a method for testing whether what is rendered to the canvas meets these limits written something like

function setup() {
  createCanvas(400, 400);
  checkFlashing();
}

that would throw a friendly error if and when the sketch fails the test. This could share a helper function with the contrast function as both are based on relative luminance.

Calculating relative luminance across the canvas every frame would likely be quite computationally expensive, but for running a test, I think that would be acceptable.

@ksen0 writes

[open for discussion] Flashing light - functionality I agree on, the syntax I'm not sure about. I think rather than something like checkFlashing() it would be better to have a class that may later be extended, e.g., A11yTools.checkFlashing() or something. It would also be great to get some feedback from others on this API design.

@calebfoss writes

I appreciate the thinking ahead for packaging together multiple accessibility tools. Historically p5's design has avoided dot notation for the most beginner friendly end of the API. It would be great to start p5 creators early on accessibility tools, so that would be an argument for a global function. Then again, my recent suggestion in #6971 goes against that. Were you to go the global route for both, you could go with the contrast() function I originally proposed. Organizing accessibility tools in the same reference section would be another way to group them together. That would also help with the fact that textOutput() and gridOutput() to me don't sound like they would be accessibility features by their names. So I agree - a few different approaches to be discussed that would benefit from more perspectives.

From #7488

@calebfoss writes

I also wanted to mention another thought that came up about my proposal in #6992 for detecting issues pertaining to WCAG 2.3.2. It occurred to me that shaders may be a possible route to efficiently calculate differences in luminosity. Not sure about specifics (sending 2D canvas graphics through shaders may have its own performance issues?), but this sounds like the kind of thing @davepagurek would have some great insights on. Btw @davepagurek, the new textToModel method on fonts is a super awesome feature that I think will get a ton of use.

@davepagurek writes

@calebfoss I think shaders can help power something like that! if we take a snapshot of the frame before moving on to the next one, we can compare with the previous frame's snapshot and see if the luminosity changed by a certain amount.

Some notes:

Even with shaders, capturing and checking images will be noticeably slower than not doing so (maybe comparable to a full-canvas filter?), so we'd maybe encourage this to be something to run once while writing your code and then take out before you publish.

We'd need to distill the per-pixel calculation from the shader into a single value. We could load the pixels of the shader output and check if any has a bad value in JS, but there will be a performance cost for the gpu-to-cpu transfer on larger canvases. A more efficient approach could be to running an amalgamation shader on ever smaller bitmaps, maybe halving the size each time and outputting an average or min or max of the 4 source pixels that got condensed into one output pixel until we have just one value left, so that we have just one value to transfer to the CPU.

We'd have to figure out what that amalgamation operation would need to be in order to pass the criteria for a flash, which depends both on area and difference in luminosity. Looks like we'll need to have a sum of the number of pixels affected? Possibly also the bounds of the affected area? So maybe it'd have to do a sum in one channel, and some mins/maxes in others to return all the data needed

edit: Also, we have a new addon api that should make it easier for us to register a post-draw hook like that!