2.3.2 Three Flashes (in the wild!) - or not

[detlevhfischer]

Hi, I just put this here because I rarely come across pages with flashing content - today I did, and I re-read the SC to check if this page
https://www.interviewmagazine.com/culture/chris-kraus
would fail.
The first question is the frequency of flashing: more than three flashes in any 1 second period probably refers to the appearance of the changed state, not any change between states? If the former is correct, then the flashing here is too slow to be a FAIL; if each state change is counted, it may be just within the second.
As to the second condition (10 degrees visual field on screen) I have no clue how to test that reliably except for taking cover in the first note of the "general flash and red flash thresholds" glossary entry that says the approximation of a rect of 341 x 256 pixels is an approximation when content is "viewed at 1024x768 pixels" (what difference would viewport size make here, I wonder - is it not the zoom factor that would need mentioning).
The flashing image has 600 x 300px so I guess the size would be large enough for a FAIL, but the frequency arguably not.
Please take this as a Sunday pastime - I know there are more important things to discuss...

[patrickhlauke]

based on https://www.w3.org/TR/WCAG21/#dfn-flashes a flash is s pair of changes, i.e. the change from b/w to w/b and back to b/w counts as one flash.

as for the second part...i think i've mentioned before how the whole "degree of visual field" wording there is incomprehensible, and outdated, since it doesn't take into account different monitor sizes, viewing distances, etc (or at least, it doesn't explain them properly). zoom will of course be a factor in the real world, but i believe zoom is out of scope for SCs (as they're down to user preference / a user's change). I'll note as well that PEAT https://trace.umd.edu/peat (to my knowledge still the only "proper" tool that's supposedly able to make determinations about whether or not flashes are acceptable or not) only works (at least last time i checked it) by resizing a browser window to 1024x768 and then doing its analysis...which of course completely misses testing on any other resolutions, and any other changes in breakpoints/layout. and yes, doesn't take viewing distance etc into account. in terms of viewing distance, the only sensible approach is to anchor everything on CSS ideal pixels, of course. but the definition/explanation would need to be freshened up to account for stuff...and we need tools that are better than PEAT (where you can at least test at different breakpoints)

[patrickhlauke]

x-ref #553 and #585

[patrickhlauke]

as for different breakpoints, the definition may need to be changed to make the flashing area relative to the viewport size (under the assumption that the viewport size will be what is occupying the 10% of the user's visual field?)...so this will yield dramatically different considerations based on the actual viewport size/breakpoint.

Just doing a rough comparison here between large/medium/small viewports (call them "desktop", "tablet", "mobile" if you will)...it's clear that if the flashing element remains the same CSS pixel size, it will occupy more and more percentage of the overall viewport...so something that might pass PEAT (tested just at 1024x768) may well catastrophically fail at smaller viewport sizes, but you wouldn't know by just checking at that one size.

• the flashing advert at desktop size, occupying less than a 25% of the overall page/viewport

• the flashing advert at tablet size, occupying somewhere between a 25% and 30% of the overall page/viewport

• the flashing advert at mobile size, occupying 60%-70% of the entire page/viewport

[patrickhlauke]

actually, i think i managed to confuse myself here in the process. making it relative to viewport dimensions per se won't work, as the assumption is that as viewport sizes get smaller, users will hold the device further away, so that in real-world terms, the ideal CSS pixel is always roughly perceived as the same size. long story short: the definition should probably be updated to just state a particular size in CSS pixels for the area that is flashing, which are then valid for all breakpoints/viewport sizes/viewing distances (as yes, with the example above, on mobile-sized viewports the advert does take up almost the entire viewport, but the user will be holding their mobile at arm's length, so in terms of their overall field of view, it won't be as dramatic as if the advert was covering the whole of a medium or large viewport as those are assumed to be viewed much closer and occupy more of the actual field of view of the user).

long story short, instead of the whole ".006 steradians within any 10 degree visual field on the screen", start talking about just CSS pixel dimensions outright, and move the "science" into notes instead that justify those dimensions, rather than the other way around...as i sincerely doubt any web designer/developer would know how to even start thinking about WTH ".006 steradians" even means...

[detlevhfischer]

Fully agree with the simplification of measurement that Patrick proposes. It still leaves open what approach to take with irregular or distributed shapes, (think of dots firing randomly like firework all over the viewport) but it would still give evaluation a far more usable basis.

[mraccess77]

Well people with low vision won't be holding their phones at arms length. Seems like the size of the area can have a bigger of an impact to users with low vision.

[patrickhlauke]

so how to square that @mraccess77 ? it almost goes towards needing 2.3.2 Three Flashes which is AAA, as potentially even the smallest flashing area can, at sufficient magnification, become large enough to become problematic and effectively fall foul of the threshold defined in 2.3.1

[mraccess77]

It's not so much magnification but the fact that people with low vision hold things closer effectively limiting the visual field. The field of view is also steeper -- that's why privacy screens often block out things for people with low vision . We benefit from monitors that can be seen from the side. Even without magnification users can miss things not near the focal point when they are looking closely at it and other page content is on-screen but no in the visual field.

[patrickhlauke]

the effect is the same though - same viewing distance + higher magnification / no magnification but closer viewing distance. end result is that things take up a larger amount of the visual field. magnification can at least potentially be detected/tested for. shorter viewing distance cannot. but the end result is that this makes potentially even relatively small (in absolute CSS pixel dimensions) areas of flashing content that would nominally be ok based on the "steradians..." thing fail...meaning that, to be safe, all flashing should just be failed? don't see any other safe way of expressing this otherwise. or - as is currently the case - leaving the exception still at AA and the no exception at AAA. or bumping them all up by one level (exception to A, no exception to AA)

[mbgower]

@patrickhlauke I thought I'd look at old topics labelled with "WCAG 2.2," and this was the oldest that came up. (The idea was that maybe older topics would be faster to resolve or to unlabel as "WCAG 2.2")

I'm trying to time box myself to 1 hour on any of these. Would you please glance at this PR and tell me if it can be a start to what you are proposing, and whether you think it is worth tackling for 2.2? My sense is it should be pushed off to 3.0, but I wanted to give it a fighting chance.

#2127

[patrickhlauke]

lovely stuff, thank you @mbgower

[alastc]

Apologies, we'd accepted the PR a while back.

However, probably good to update the group on the outcome (based on the survey results).

[alastc]

The group (re) agreed the PR, and that we can close this issue.