Problems with WCAG 2.0 Flash Definition

[dd8]

I think there are a number of assumptions in the flash definition:
https://www.w3.org/TR/WCAG21/#dfn-general-flash-and-red-flash-thresholds

Some of these are no longer true due to the introduction of high pixel density displays and the updated definition of the px unit in CSS 3:

1. If the definition is meant in terms of device pixels then the note about 341 x 256 pixels doesn't work for high DPI retina displays.

2. If the definition is meant in terms of CSS pixels then the size calculations are wrong since the CSS spec defines the visual angle of a CSS pixel: https://www.w3.org/TR/css-values-3/#reference-pixel (10 visual degrees is 10 degrees / 0.0213 degrees per pixel = 469 CSS pixels)

3. Universally available browser zoom means that content falling under the sizes in 2.3.1 Three Flashes or Below Threshold threshold can become large enough to cause seizure problems when zoomed. Does this mean that anything failing 2.3.2 Three Flashes should fail 2.3.1 due to browser zoom?

[patrickhlauke]

My personal interpretation here would be:

1. back in the days of WCAG 2.0 where this was defined, a physical/device pixel was the same as a CSS pixel...but nowadays, the definition should be interpreted as CSS pixel.

2. i'll trust your maths skills here - for my own part, the whole ".006 steradians within any 10 degree visual field" is incomprehensible and impenetrable (and the same holds true for any developer i've spoken to about this). i'd also note that the definition for the reference pixel is idealised, and real-world devices and user agents, though they often come close, don't really take this into account.

3. i'd say that browser zoom is a user choice/setting, and not something that you'd take into account when testing (similar to the fact that if a user goes closer to a screen, even assuming the browser/OS followed the actual idealised reference pixel dimension, that would also increase the size of any flashing area within their field of view).

[dd8]

I think CSS pixel is probably the best/only option - and is backwards compatible with the 96-dpi pixel common when WCAG 2.0 was written. It's also defined as a visual angle, which ties in well with the rest of the definitions (or at least the parts I understand)

It's also not defined what the 'maximum relative luminance' is in this definition. It's probably the relative luminance of black vs white (i.e maximum contrast) but difficult to be certain given how opaque the rest of this definition is.

Given flashing content can cause seizures, with consequences including death, I think this success criteria should be evaluated very conservatively. Browsers sometimes remember zoom settings, so a user may end up on zoomed flashing content quite unexpectedly.

[alastc]

So there's a specific issue on the dimension usage, #585, are the other questions answered?

[dd8]

It's still not clear what 'maximum relative luminance' means in the general flash definition. It could mean any of:

• the relative luminance between the darkest and lightest colors possible (black and white)
• the relative luminance between the darkest and lightest colors on the page containing the image
• the relative luminance between the darkest and lightest colors across all frames of the image
• the relative luminance between the darkest and lightest colors in a single frame of the image

[patrickhlauke]

Agree that wording is dense and unclear.

A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance where the relative luminance of the darker image is below 0.80

My interpretation for that "maximum relative luminance" is that it refers to the relative luminance between the darkest and lightest colors possible (black and white). So, a flash is a change of 10% or more of the possible extreme change from white to black / vice versa. Assuming the math is linear, and not something logarithmic or exponential or whatever, if the extreme contrast ratio between pure white and pure black is 21:1 (at least per Color Contrast Analyser, but I believe its maths is correct), then a 10% change in relative luminance would be a contrast ratio of 2.1:1 between the two opposing colors.

Now personally, I find the second bit of that sentence even more vague/confusing... "where the relative luminance of the darker image is below 0.80". Relative to what? Also, why is this now talking about "image", rather than a specific color? Or does this mean the relative luminance overall across all of the image/area where the flashing occurs? This feels a bit out of context to me in any case.

[awkawk]

Should we mark for review for WCAG 2.2?

[alastc]

Ok, so it sounds like the changes would be to:

• Clarify it is CSS pixels;
• Re-calculate the area (or replace the area definition) with something equivalent (see WCAG 2.1 Understanding 2.3.1 - missing/vague dimension definitions #585 and Problems with WCAG 2.0 Flash Definition #553);
• Find out what the relative luminance values actually refer to, and/or replace that with what we think it says?!

I'm working through the 'misc' issues marked with WCAG 2.2 now, so PRs welcome...

[alastc]

The size metric in the understanding is updated in #2127

[Myndex]

I reduced this topic to a human-readable form earlier in the year for a whitepaper

Edit to fix: link to whitepaper.

It also includes the most recent recommendations of the Epilepsy Foundation of America.

Flashing at rates higher than 3 per second over a screen area greater than about 300px square has been shown to induce photic seizures in some people....

Single, double, or triple flashes in one second are acceptable, but a sequence of flashes is not recommended when both of the following occur:

1. More than three flashes within any one second period.
2. From the minimal expected viewing distance, the total area of concurrent flashes subtends at the eye a solid angle of <0.006 steradians (approximately 300px square).

And

When the light–dark stripes of any pattern are larger than 300px square (approximately) and the luminance of the lightest stripe is more than 50 cd/m², the pattern should display no more than:

1. Five light–dark pairs of stripes, if the stripes change direction, oscillate, flash, or reverse in contrast.
2. Eight light–dark pairs of stripes, if the pattern is unchanging or continuously and smoothly drifting in one direction.

It should be noted that the 3 per second rule might be lowering to 2 per second.

300px in CSS reference px is based on a minimum expected view distance.

FOR FLASHES: The actual luminance variance is not specified for flashes, as that is not a useful metric, as other psychophysical phenomenon come into play. For instance, flashing between full blue and full red #00f and #f00 is a luminance difference of only 11, but some studies indicate could result in seizure.

Tangent: "Flashing" means rapid changes blow the integration point. For practical purposes we can consider the integration point as above 50 Hz, which is the flicker rate for a PAL/SECAM monitor.

Please let me know of additional questions.

Andy

[mraccess77]

It might be worth noting some users such as users with low vision may not be viewing from the standard distance and thus the impacts on flashing may be greater for these populations when there is an intersection between disabilities.

I also wonder if any of these are affected by viewing when in a dark environment where only the monitor is present without other ambient/surrounding lighting.

[Myndex]

It might be worth noting some users such as users with low vision may not be viewing from the standard distance and thus the impacts on flashing may be greater for these populations when there is an intersection between disabilities.

Indeed, and I was thinking about this in view of our discussion regarding zoom/resize and proximity.

I am working out the math now, and I think it is worth recalculating — I am also reviewing the EFA's rec. again.

I also wonder if any of these are affected by viewing when in a dark environment where only the monitor is present without other ambient/surrounding lighting.

That is discussed as I recall, I'll review again. When I wrote the above, I recall that is was a factor that was considered in the values given.

[alastc]

This was discussed today, and there were two outcomes:

1. The intended meaning was: maximum white sRGB.
2. This does need a re-write.

Someone (possibly me) needs to have a quick look at the normative definition and the understanding document to see if (1) is a small edit.

There is also a task to re-write it, but I think that would be a post 2.2 thing.

[alastc]

Looking at a small update to the general flash definition:

A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance ...

The link to relative luminance then defines the min and max as 0 and 1, therefore "maximum relative luminance" = 1.

That aligns with what @GreggVan said in the survey about the original intent, which was maximum white (in sRGB).

So to answer the question above, it is the brightest possible colour in the colourspace (sRGB).

Now given the question (and that we couldn't easily answer it), that isn't very clear. Would it help to put something in brackets after that? E.g.

10% or more of the maximum relative luminance (1.0) where the relative luminance...

[patrickhlauke]

I see i mentioned some of this earlier in the thread, but since you're asking about adding a parenthetical or other additional explanation: would it make sense to express that whole "10% of maximum relative luminance" in terms of colour contrast instead? assuming that it's linear (?) that would mean the colours, when compared next to each other, would have a contrast ratio between them of at least 2.1:1 (as 21:1 is the ratio between black and white). just thinking that would make it more easily testable/verifyable, since the concept of contrast ratio is what auditors are already used to.

also, note this from my comment earlier:

Now personally, I find the second bit of that sentence even more vague/confusing... "where the relative luminance of the darker image is below 0.80". Relative to what? Also, why is this now talking about "image", rather than a specific color? Or does this mean the relative luminance overall across all of the image/area where the flashing occurs? This feels a bit out of context to me in any case.

[alastc]

would it make sense to express that whole "10% of maximum relative luminance" in terms of colour contrast instead?

It makes sense to me, but I'm not entirely sure that it is linear?

I agree the whole thing is hard to understand, but I'm inclined to take a step back and get some help re-jigging the whole thing for WCAG 3.

[dd8]

I think re-jigging is probably needed. CSS Colors 4 introduces some extra complications over sRGB

1. display-p3 in Colors 4 allows for more intense colors than sRGB (e.g. much brighter reds). All modern Macs / iPads / iPhones use display-p3 devices. This may impact the red flash definition, since there are more saturated reds in the display-p3 color space:
   https://webkit.org/blog/10042/wide-gamut-color-in-css-with-display-p3/

2. Colors 4 allows specifying extra bright whites (e.g. flashes of sunlight reflecting off water) using lab() colors which can be brighter than rgb(255,255,255) - the brightest white in sRGB. This may pose difficulties if the maximum relative luminance definition is done in terms of the brightest white in sRGB:
   https://www.w3.org/TR/css-color-4/#specifying-lab-lch

color.js by the editors of CSS Colors 4 is useful to try stuff out in different color spaces like lab and display-p3:
https://colorjs.io/apps/convert/?color=lab(%20400%25%2C%200%2C%200%20)&precision=6

[mraccess77]

I have an iPhone 12 pro and I have seen some of the intense colors that almost look like they are glowing/reflecting light themselves. So this is a good point to consider for displays with these capabilities.

[patrickhlauke]

but I'm inclined to take a step back and get some help re-jigging the whole thing for WCAG 3

that still leaves the definition/wording that even WG members can't agree/immediately understand in the standard that auditors currently, and for the foreseeable future, have to test against. not an ideal situation (though yes in fairness, I don't think in real-world testing the situation has arisen all too often that there's been some "must test if this color swap counts as a flash or not" uncertainty)

[alastc]

There was an interesting thread on colour spaces on twitter, linking to the end of the thread so it includes the tweets intended.

It appears that HDR displays can show a red so pure it is invisible if you have protanopia (missing red-cones).

Another interesting aspect was that, from what Jen Simmons showed at the top of the thread, you will be able to provide CSS and assets for each colour space. I.e. you could provide P3 or (in future) HDR colors for those with those displays, and have sRGB fall-backs. That means you'd need to test multiple colours and have a tool with different settings for each colour space.

Anyway, that's a bit off topic, but will impact the relative luminance calculations in future.

@dd8 Have we answered the questions above as best as possible in the current framework? (E.g. max relative luminance = 1).

@patrickhlauke I agree it's not ideal, but it's been >10 years and I can't think of a time in our audits where it has mattered in practice. (There has been occasional flashing, but it's been clear cut and often tied in with pause/stop/hide.) I guess if you have to analyse 100s of videos it would be different, but I'd be downloading PEAT and learning how to use that if it were the case.

There wasn't somewhere in the understanding doc to just drop-in and explanation of max relative luminance, if we add something I think it would need quite a big explanation to set the context.

[bruce-usab]

First note under relative luminance definition is caveat that our maths are only for sRGB. The definition might still be okay for P3 and HDR.

I agree that ten+ years is evidence that the dense prose is tolerable.

FWIW, the current version of PEAT seems to be so buggy that the Trusted Tester folks gave up.

My current heuristic is to set a timer for ten seconds. Can I count the number of strobes? If yes, then 2.3.1 is a pass — because that count will be less than 30! If no, then page is too close for comfort!

I had some concern that our use of relative luminance was not 100% consistent with Harding-Binnie, but I have convinced myself that is okay. Unfortunately, that led to me looking at our MathML version...

[patrickhlauke]

I agree that ten+ years is evidence that the dense prose is tolerable

evidence that nobody tried to actually read/understand it ;)

also, i'll mention again regarding PEAT that in this day and age of responsive layouts that can potentially change, it's fairly limited/useless since it insists on running its test (when it works) at that one specific resolution only.

[bruce-usab]

evidence that nobody tried to actually read/understand it

That is a fair paraphrase!

Part of the problem is that there is some recursion. Our flash definition defines itself as being something which a danger for seizures, and a note links to the flash thresholds. The flash thresholds (in addition to other defects) links to the flash definition, so it is circular. I will propose something that I believe to be editorial.

[bruce-usab]

flash: a pair of opposing changes in relative luminance that can cause seizures in some people if it is large enough and in the right frequency range

Current:

general flash and red flash thresholds
a flash or rapidly changing image sequence is below the threshold (i.e., content passes) if any of the following are true:

1. there are no more than three general flashes and/or no more than three red flashes within any one-second period; or
2. the combined area of flashes occurring concurrently occupies no more than a total of .006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance

where:

• A general flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance where the relative luminance of the darker image is below 0.80; and where “a pair of opposing changes” is an increase followed by a decrease, or a decrease followed by an increase, and
• A red flash is defined as any pair of opposing transitions involving a saturated red

Proposed:

general flash and red flash thresholds
a pair of opposing changes is below the threshold (i.e., content passes) if any of the following are true:

1. there are no more than three general flashes or red flashes within a one-second period; or
2. the combined area of flashes occurring concurrently occupies no more than a total of .006 steradians within any 10-degree visual field on the screen (25% of any 10-degree visual field on the screen) at the typical viewing distance

where:

• a pair of opposing changes is area of transition from one relative luminance to another, including any rapidly changing image sequence, and is an increase followed by a decrease, or a decrease followed by an increase; and
• a general flash is a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance where the relative luminance of the darker image is below 0.80; and
• a red flash is any pair of opposing changes involving a saturated red.

[bruce-usab]

I will mention that, while the edit I propose above is related to the 2.0 Flash Definition, it is not responsive to the three enumerated items in OP. It might be better as a new issue, or might be better to drop it.

[bruce-usab]

I will note that updating Notes associated with 2.3.1 was the main topic of AGWG conversation today (8/9/22) and quite on point for issues named in OP.

[alastc]

Hi Bruce,

I like your suggestion above, but it essentially makes the definition of 'flash' redundant, which will have ripple effects.

I think the discussion above, updates from the last meeting, and adding (1.0) as the max brightness should wrap this issue up?

[bruce-usab]

I agree my suggestion is no longer relevant with the recent updates for Flash and Red Flash Threshold from Trace (Gregg and Bern).

[alastc]

Going back to the original questions:

• If the definition is meant in terms of device pixels then the note about 341 x 256 pixels doesn't work for high DPI retina displays.
• If the definition is meant in terms of CSS pixels then the size calculations are wrong since the CSS spec defines the visual angle of a CSS pixel: https://www.w3.org/TR/css-values-3/#reference-pixel (10 visual degrees is 10 degrees / 0.0213 degrees per pixel = 469 CSS pixels)

The first note under general flash and red flash thresholds has been updated, this is as far as the group wished to go:
"For general software or Web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances (e.g., 15-17 inch screen at 22-26 inches). This resolution of 75 - 85 ppi is known to be lower, and thus more conservative than the nominal CSS pixel resolution of 96 ppi in CSS specifications. Higher resolutions displays showing the same rendering of the content yield smaller and safer images so it is lower resolutions that are used to define the thresholds. "

Technically you could do your own calculations based on steradians, but if you're following the guidance that isn't changing.

Universally available browser zoom means that content falling under the sizes in 2.3.1 Three Flashes or Below Threshold threshold can become large enough to cause seizure problems when zoomed. Does this mean that anything failing 2.3.2 Three Flashes should fail 2.3.1 due to browser zoom?

There are several new paragraphs of content in the understanding document (starting "With the proliferation of devices...") aiming to deal with the CSS sizing, zoom level, non-sRGB content, and looping GIFs.