Success Criterion 2.3.1 - Three Flashes or Below Threshold - Level A

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#three-flashes-or-below-threshold

Share your thoughts for applying to mobile apps as a comment below.

[julianmka]

I would think this applies directly to the mobile context.

[jha11y]

Needs updated definition for "general flash and red flash thresholds" based on group conversation

[JJdeGroot]

Discussed in today's meeting.

21 August 2024

[Source](https://www.w3.org/2024/08/21-matf-minutes.html#t03) JJ: Summarizes current activity on this SC's github issue. Joe_Humbert: This will require guidance on testing. Joe_Humbert: This might happen if devs create a custom animation. Regular OS animations already take this SC into consideration. JJ: Testing might be similar to ICT Detlev: The WCAG SC defines "threshold" of 10 degree visual field. Can make testing more difficult. Detlev: Only AAA conformance rules out any flashing that occurs more than 3x/second Detlev: The size of the flashing area depends on device size so success/failure could vary. JJ: Seems like applying is pretty direct but testing is more complicated. GleidsonRamos: OS animations and transitions are within the SCs guidance, but Flutter and other cross-platform technologies allow animations that are much more disruptive JJ: Had a recent experience where custom animations were quite busy and distracting. Detlev: Animation isn't flashing. Hasn't seen any transitions that include flashing. JJ: Hasn't failed this SC, nor have colleagues. GleidsonRamos: In a stock app, transition between positive and negative values can generate flashes. Not usually faster than 1/sec, but if animations get queued they can occur very frequently. GleidsonRamos: Flashes occupied ~10% of screen JJ: In first draft, we can just say whether the SC applies as written. In follow-up versions, we can address testing. JJ: Would be helpful to have a failing example. Joe_Humbert: Clarifies that the guideline applies but Note 1 in WCAG 2.2 needs to be tweaked to address mobile apps.

[julianmka]

Based on previous task force conversation, this SC can be applied to native mobile apps and mobile web with minimal or no deviation from WCAG2ICT.

Proposal In MATF's first draft of guidance, this SC's section will read as:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.3.1, replacing “Web pages” with “screens or views” , “the whole page” with “the whole screen or view”, and “the Web page” with “the screen or view”; and removing “See Conformance Requirement 5: Non-Interference”.

With these substitutions, it would read:

2.3.1 Three Flashes or Below Threshold: [Screens or views] do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

NOTE Since any content that does not meet this success criterion can interfere with a user's ability to use the whole [screen or view], all content on the [screen or view] (whether it is used to meet other success criteria or not) must meet this success criterion.

Please indicate your agreement with a thumbs up emoji 👍, or if you disagree, use the thumbs down emoji 👎 and elaborate in comments.

[Keanem6]

I voted down because of the text of the definition for “general flash and red thresholds” is extremely technical in nature and to me very difficult to interpret. I know we're addressing testing later but if we're unsure how it can be tested then I don't think we can have it as a requirement. My recommendation is that we leave out "or the flash is below the general flash and red flash thresholds.". I might be in the minority here but that would be my take.

[jha11y]

@Keanem6 I'm not sure we can significantly alter the SC text. Even if we can, I'm sure the larger WG would need really good reasons for the change. @JJdeGroot can we make big changes?

[jha11y]

we might be able to provide a new definition, which would not change the original SC text

[JJdeGroot]

Even though the definition is very technical, I wouldn't change it because it can be applied to apps as is. It's just as difficult to apply it to websites.

When you leave out the threshold exception, you get very close to the AAA variant: https://www.w3.org/WAI/WCAG22/Understanding/three-flashes.html

[AlainVagner]

I am wondering if we should mention something about screens that are too small to be considered here, e.g. smart watches. A small Apple Watch series 9 has for example a viewport size of 176 x 215 css pixels which is smaller than the minimum combined flashing area of 341 x 256 css pixels.

[julianmka]

Notes from MATF meeting 9/4/2024

Illai: Alain brought up watches, what about other devices? Joe_Humbert: Apple watch example - not only a different device but also a different OS. Alain: Not sure if smartwatches are in scope of MATF. Alain: Could we clarify what's in scope for mobile applications in terms of other hardware? Jamers: WCAG2ICT is about non-web space, we're here for mobile/smartphone devices. Readers of our docs would benefit from clarifying scope and there are probably questions out there about smartwatches etc. Jamers: Need to clarify scope within this team. [Several others agree with Jamie's comment re: clarifying scope of devices] Joe_Humbert: May need to define other terms and platforms. Joe_Humbert: We can limit scope of our first draft so this doesn't drag on forever. Aashutosh: Concerning this SC, people use their mobile devices in the dark and in environments where flashes/light can have a greater impact.

After discussion and voting at the meeting today, the task force members present accepted the proposed language for the first draft of our guidance.

[JJdeGroot]

Closing this issue because the draft language has been accepted.