2.2.2 Pause, stop, hide SC text should make it clear it applies to all content

[maryjom]

Opening this issue due to a public comment, Issue 232, we received on the WCAG2ICT FPWD. The issue indicates that the normative SC text in WCAG says "information" rather than "content" and thought it was interpreted to mean that the SC doesn't apply to all content on the web page. This brought in question the WCAG2ICT notes that indicated the SC applies to all content and the reviewer questions whether WCAG2ICT is expanding the scope of the SC.

In WCAG, the non-normative Note 2 does say, "all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion." It would be most helpful to have a clarification in the WCAG errata that normatively, this SC applies to all content, as it seems that was the intent for this SC. SC 2.2.2 is not just limited to content that is considered "information". Otherwise, the notes and understanding should be updated to clarify what type(s) of content are out of scope for meeting this SC.

See also the WCAG2ICT TF discussion on this, documented in the 5 October meeting minutes.

[melaniephilipp]

A while back, I was interested in the history of SC 2.2.2 Pause Stop Hide, and the apparent discrepancy between the use of “information” in the normative language and the broader application to “content” in the Understanding document. I dug back into the version history to see if that revealed anything about the intent of the SC. I found the following:

In the 2006/04/27 Working Draft, both parts of today's SC were scoped to "content". In the 2007/05/17 Working Draft, the blinking part was scoped to "content" and the moving part was scoped to "information" In the 2007/12/11 Working Draft, blinking, scrolling and updating were scoped to "information" and an additional clause was added for moving "decorative" content In the 2008/04/30 Candidate Recommendation, the decorative clause was removed and only "information" remained. A note was added that the SC was at risk. In that note, the "fall back" was to add "decorative content" back in "If implementation feedback from users indicates that the current version is less helpful than the version from 11 December 2007, or if it is determined that assistive technology can provide a way to stop moving content, this success criterion will revert to the Level AA fallback wording." Decorative content was NOT added back into the 2008/11/03 Proposed Recommendation doc.

Minutes from that period of time were not really minutes, mostly a summary of resolutions. The issues referenced in bugzilla are no longer available (the issue links go to blank pages), so I can't see WHY the SC evolved from "content" to "information" and "decorative content" was added and removed.

But given the history I can see, it confirms my feeling that the SC was deliberately scoped to "information" not "content" and the Understanding doc was never updated to reflect that.

[patrickhlauke]

as there doesn't seem to be a normative definition of what "information" is (as opposed to general "content"), it's still fairly unclear what the supposed distinction here is. and, as pointed out elsewhere, even if something is only decorative, it can cause distractions and difficulties that this SC tries to address (and nowadays, there are more robust mechanisms in place, such as prefers-reduced-motion and similar settings, that can help authors pause/stop/hide things easily without having the undue burden of creating their own mechanism)

[mbgower]

I suspect at some point there might have been an attempt to separate text content from non-text-content.

Having spent some time discussing this SC for WCAG 3.0 work, I can see that there may very well be advantages breaking it up that way.

However, since the Understanding document specifically calls out motion effects for things that are clearly not just text content (e.g., page loading animations), I think any intended nuance is lost -- if that's even the nuance that was being attempted. Thanks, Melanie for digging up to the old minutes; too bad they're inconclusive.

[melaniephilipp]

@mbgower The minutes may be inconclusive, but I think the deliberate change from "content" to "information" in the normative text, and the choice NOT to add back the bit about decorative content, is not inconclusive (sorry for the double negative). The Understanding doc pre-dates the normative changes. In my opinion, it goes beyond the normative requirements.

[maryjom]

@mbgower Note 2 for 2.2.2 Pause, stop, hide in WCAG also goes beyond "information" by saying "all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion." This makes the language contradictory and therein lies the problem of varying interpretations.

[mbgower]

Hmm, I think my comments may have been poorly expressed.

So let me first say I think this SC should apply to all content.

Besides the technical note, it is expressly called out in the Conformance 5.2.5, which I believe is normative.

In addition, the following success criteria apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page: 1.4.2 - Audio Control, 2.1.2 - No Keyboard Trap, 2.3.1 - Three Flashes or Below Threshold, and 2.2.2 - Pause, Stop, Hide.

I also agree with Patrick's comment that since "information" isn't defined, I'm not sure we can say anything definitive about a difference between "content" and "information".

Unless I'm missing something in the meeting minutes, I'm not sure what we can interpret from the decision to leave out "decorative". Was it left out because people felt it was redundant, having already been captured in the preceding bullets? Or was it left out because there was interest in allowing purely decorative information to flash away to its heart's content? The former seems like a much more likely scenario to me.

[alastc]

My guess would be that Pause, Stop, Hide was at-risk (with the decorative fallback) in case of push-back about feasibility. If the industry pushed back on the whole concept, that would be a little escape clause.

I'd also guess that the scope being 'information' is an artefact of the original drafting, and if it had come up as a question in time, it would have been changed to 'content'.

Perhaps @GreggVan can remember?

In practice though, has it made any difference so far? I can't think of ever failing a site on this and someone pushing back with "Oh, it's content, but it's not information..."

[mbgower]

This may be a good case for an erratum to change "information" to "content". We already have it as normative in the conformance, as noted above, so this seems to be correcting a langauge glitch, not changing the meaning.

[melaniephilipp]

My read of the evolution of the normative SC text (as outlined above) is that it was deliberately changed to "information". It isn't a language glitch.

[CharlesBelov]

As someone who is distracted by any movement on the page that I didn't specifically request, whether informative or not, I would hope that the SC applies to all content.

[rvantonisse]

In practice though, has it made any difference so far? I can't think of ever failing a site on this and someone pushing back with "Oh, it's content, but it's not information..."

This exact thought is what I got when I read the word "information" in this SC and made be browse the WCAG issues. I have always thought this SC should apply to all content. Because of the intention and addition to the non-interference clause (5.2.5).

The word "information" confuses me here, due to other usage in WCAG like in 1.3.1 Info and relationships which targets visually presented content that conveys information.

Rephrasing "information" as "content" OR adding "information" to the glossary, would make it clear to me this SC is indeed targeted to all content or not.

[rscano]

Rephrasing "information" as "content" OR adding "information" to the glossary, would make it clear to me this SC is indeed targeted to all content or not.

Fully agree.

[CharlesBelov]

Also needs to be clear it applies to things like motion backgrounds including background videos that autoplay.

[rscano]

Also needs to be clear it applies to things like motion backgrounds including background videos that autoplay.

Agree, always referred to limits defined by SC: "For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, ..."

[patrickhlauke]

bringing this back to something actionable then...are we agreed (or not) that "information" in this context was used as a handwavy way to mean "anything that moves/blinks/scrolls/animates" (i.e. "information meaning any visual information, any visual content, anything visual"), and that it does not imply that the SC only applies to "information as in meaningful content that conveys information"

if so, a note in the understanding document that somehow tries to clarify this seems the most logical next step...happy to take a stab at it if so.

and i'm suggesting a note in understanding, because:

• changing the actual word in the normative SC would cause a LOT of process grinding, as it's a late stage normative change to the words of the SC (and associated pain with "do we also update this retrospectively? do we just note it as an erratum? etc")
• adding a definition for "information" would also be a normative change (as above), but then would further cause problems because that term is used in different ways elsewhere (as @rvantonisse noted, in 1.3.1 Info and Relationships for instance)

[kimviens]

Hello everyone, I want to jump into this conversation. While testing against this criteria, I realized that the vague term of "information" makes the criteria almost impossible to test against unless I am relying on Sufficients/Failures techniques.

I am facing a situation where a big animation on the front screen of a webpage that never stops is pretty distracting, but since its decorative, it is not communicating information? Is it a pass? I don't know.

How I would approach this is to first figure out if this new thing I heard of "prefers-reduced-motion", which is not new to you guys, supports the definition of accessibility supported. If it is, it might be the golden key to simply add to the notes that supporting "prefers-reduced-motion" passes.

That way:

1. people that need all content to stop moving get to use that functionality
2. insdustry keeps their animations
3. its a single line of text that can be added to the success criteria

"Prefers-reduced-motion" almost becomes like the autocomplete attribute of input purpose.

[JulietteZenyth]

Hi all,

From my perspective, and supported by conversations with other professionals, implementing prefers-reduced-motion does not meet SC 2.2.2.

Users may be accessing the content on a shared or public computer, may not have permission to adjust browser settings, or may not know that they can.

Even if the moving content is decorative, it still must pass 2.2.2. The Non-interference [https://www.w3.org/TR/WCAG22/#cc5] section of WCAG makes this clear:

"In addition, the following success criteria apply to all content on the page, including content that is not otherwise relied upon to meet conformance, because failure to meet them could interfere with any use of the page:

• 1.4.2 - Audio Control,
• 2.1.2 - No Keyboard Trap,
• 2.3.1 - Three Flashes or Below Threshold, and
• 2.2.2 - Pause, Stop, Hide." The decorative background animation is not otherwise relied upon to meet conformance, but still has to meet the requirements of 2.2.2.

[edited to remove the email previous message thread]

[giacomo-petri]

From my perspective, and supported by conversations with other professionals, implementing prefers-reduced-motion does not meet SC 2.2.2.

Users may be accessing the content on a shared or public computer, may not have permission to adjust browser settings, or may not know that they can.

While I acknowledge that this solution may not be the recommended one, authors cannot depend on users being aware of the existence of assistive technologies. Similarly, they cannot be responsible if the device configuration is not allowing the user to change assistive preferences. Those providing the "shared/public device" should ensure users can access necessary technology.

If operating systems consistently support reduced motion, it should be regarded as a technology enabling users to minimize animations, akin to how screen readers allow users to perceive content through speech and/or braille formats, speech recognition technology facilitates control activation through voice commands, etc.

Additionally, regarding success criterion 2.3.3 Animation from Interactions (AAA), the sufficient technique C39: Using the CSS reduce-motion query to prevent motion ensures compliance with 2.3.3; similarly, I believe it should suffice for 2.2.2 as well.

Last, but not least, it's worth noting that offering a "Pause all animations" button at the very top of each page isn't always feasible, leading to the choice of an individual play/pause button for each animated element. In my view, a singular solution, such as the media query "prefers-reduced-motion: reduce," is more practical and tidy, not only for authors, but also for the end user.

Edit: I wasn't aware of this issue (thanks to @kimviens for the link), and coincidentally, today I happened to open an issue specifically about prefers-reduced-motion. Nevertheless, I believe the primary objective here is to clarify that in this context, "information" refers to "content" rather than strictly "informative content." Additionally, we might delve deeper into the discussion about media queries related to motion reduction in #3766.

[mraccess77]

I would consider that a decorative animation that last longer than 5 seconds would fail under the 1st part of the criteria: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to [pause], stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and