Carousels fail 2.2.1: Timing Adjustable ?!

[jake-abma]

2.2.1 is pretty clear about time limits, focussing on carousels which start playing on page load I read:

Turn off The user is allowed to turn off the time limit before encountering it

The "before encountering it" is also applicable for the next bullet so Pause, Stop, Hide is not applicable here as the escape.

The understanding says:

It also includes content that is advancing or updating at a rate beyond the user's ability to read and/or understand it. In other words, animated, moving or scrolling content introduces a time limit on a user's ability to read content.

This is most of the time applicable for carousels.

So how would carousels be possible? Only show them after you've provided a user the options to change the setting first? (or do I miss something here?)

[jake-abma]

Also the example...

A Web page has a field that automatically updates with the latest headlines in a rotating fashion. There is an interactive control that allows the user to extend the length of time between each update to as much as ten times the default. The control can be operated with either a mouse or a keyboard.

... suggests the control present is enough, but the SC text is "before encountering it" so the "automatically updates with the latest headlines in a rotating fashion" can only start when the option is given to adjust previously.

[jake-abma]

The example...

A Web page includes an animation which includes text that appears and disappears throughout. In some cases, the text is scrolling across the screen and in others, it is only displayed for a short time before it fades into the background. The page includes a pause button so that users who have trouble reading the text before it disappears can read it.

... is also contradictory as it suggests "before it disappears" and NOT "before encountering it"

[jake-abma]

Same for example: https://www.w3.org/WAI/WCAG22/Techniques/general/G198

Should "before" be replaced with "when"?

[JAWS-test]

I'm not sure I understand your question correctly. I suspect the following:

• before can be understood temporally or spatially
• spatially (visually and programmatically, i.e. in source code), the stop button is usually below the carousel and thus violates "before"
• temporally, however, I can operate the stop button before and thus the carousel would be ok

I suspect in SC 2.2.1 "before" is meant temporally rather than spatially, even if the techniques suggest that e.g. the stop button must at least be in spatial proximity to have enough time to find and operate it

[detlevhfischer]

Since the issue is of 2.2.1 is time limits I agree with @JAWS-test that the intention is to be able to extend the time limit before things change (content updates) so the meaning of the 'before' is likely temporal. Putting controls to stop above rather than below the offending content such as carousels may be best practice (though in the case of carousels it may violate user expectations built on encountering that stuff in the wild) - mandating it though to always come before the content in terms of visual position and tab order feels too prescriptive, IMO (and not backed by the normative text).

[bruce-usab]

Back in the day, it was not the intent to apply 2.2.1 to animations, including Carousels. 2.2.2 is the SC for that.

If a Carousel is a "time limit that is set by the content" then so is every video. 2.2.1 is about time limited activities. Since Carousels are not "one-and-done" I really don't think anyone should be trying to apply 2.2.1 to them.

With the benefit of hindsight, I don't think the animation example belongs in Understanding for 2.2.1.

[awkawk]

I wish that the understanding document was more clear, or if there was a definition of Time Limit. I do agree that 2.2.2 is a better fit for the auto-carousel and if we interpret time limit to mean that content is lost forever once the limit is reached, then a carousel wouldn't be part of 2.2.1.

I do think that Bruce's "one-and-done" principal makes sense here.

Without it, I would argue that the ability to use the pause/back/forward buttons on the carousel could be regarded as an in-page equivalent facilitation.

[jake-abma]

Just a quick one, be back on this one again, but check this:

Last bullet: 20 Hour Exception: The time limit is longer than 20 hours.

So, I see the time limit as when the timer kicks in till when it's finished.

Then, the previous references with "before encountering it (the time limit) makes an automatic time limit NOT appropriate.

as in: (example) a carousel can ONLY be started AFTER giving options to set settings for it...

[bruce-usab]

@jake-abma, I don't think I am following your point. 2.2.1 is an or list (at least one of the following is true). So if the 20 Hour Exception is true, then being "allowed to turn off the time limit before encountering it" is not a requirement.

[jake-abma]

Hi @bruce-usab it's about the definition for time limit, not the last bullet, that was the reference for what can be read / meant for the definition.

Is the time limit: 1. from when it starts till the last moment (the time span, time's up) OR 2. only the split second / the moment the time is up ?!

first bullet seems to hint at the second option, while the last bullet (20 hours) seems to hint at the first option.

In any way, there are problems with the normative text if only one is applicable because if the time limit is the last moment, it doesn't last for 20 hours, and if it is the time span, than you are never allowed to just start a carousel on page load, because you first need to provide options to turn off or adjust.

Hope this makes it more clear

[bruce-usab]

Sorry @jake-abma but I am still not quite following your distinction.

But FWIW I do not agree that a (typical) Carousel reflects a "time limit that is set by the content" because the information and data (the content) is not limited by the passage of time.

[jake-abma]

Hi @bruce-usab see the Understanding:

Any process that happens without user initiation after a set time or on a periodic basis is a time limit. This includes partial or full updates of content (for example, page refresh), changes to content, or the expiration of a window of opportunity for a user to react to a request for input.

It also includes content that is advancing or updating at a rate beyond the user's ability to read and/or understand it. In other words, animated, moving or scrolling content introduces a time limit on a users ability to read content.

1. This includes partial or full updates of content
2. changes to content
3. It also includes content that is advancing or updating at a rate beyond the user's ability to read and/or understand it
4. animated, moving or scrolling content introduces a time limit on a users ability to read content.

They all feel like applicable to a carousel...

And for what it's worth, the carousel was an example, not the main cause of the question, reading the SC and Understanding got me here.

[awkawk]

@jake-abma surprised that carousels aren't the focus of your question since it is in the title, first, and last sentences! :)

I think that the key here is the definition of time limit. Since it isn't defined in WCAG the standard definition applies, which is usually where things get tricky. I think of a time limit as providing a deadline for when something must be completed by, and I think that carousels provide additional opportunities to view the content so it isn't a limit in that way.

I know that this was discussed when we reviewed the carousel tutorial: https://www.w3.org/WAI/tutorials/carousels/

[mraccess77]

Many folks treat 2.2.1 are primarily about session time outs and time limits and carousels and dynamic content under SC 2.2.2. However, 2.2.1 seems to more broadly written where it could apply further to situations traditionally considered under SC 2.2.2.

[jake-abma]

Hi @mraccess77 until 2 days ago I also always saw 2.2.1 as the SC for session time outs (and carousels under 2.2.2)

@awkawk saying:

@jake-abma surprised that carousels aren't the focus of your question since it is in the title, first, and last sentences! :)

Reason: When I give a training I always re-read the SC treated that day and often I stumble across small questions / incrependencies where I try to check what the reasons were of those. In this case it was the Understanding document with (paste again) the following text:

Any process that happens without user initiation after a set time or on a periodic basis is a time limit. This includes partial or full updates of content (for example, page refresh), changes to content, or the expiration of a window of opportunity for a user to react to a request for input.

It also includes content that is advancing or updating at a rate beyond the user's ability to read and/or understand it. In other words, animated, moving or scrolling content introduces a time limit on a users ability to read content.

First thing I thought of was: Hé, this feels 100% applicable for a carousel too, but the bullets of the SC do not fit!

So, @bruce-usab after reading this text, you still say this is not applicable for a carousel?

1. Any process that happens without user initiation after a set time or on a periodic basis is a time limit
2. This includes partial updates of content
3. It also includes content that is advancing or updating at a rate beyond the user's ability to read and/or understand it
4. In other words, animated, moving or scrolling content
5. introduces a time limit on a users ability to read content.

I would say, check, check, check, check, check, but I might be missing something and would love to hear it.

Cheers!

[JAWS-test]

I don't understand why content like carousels can only violate either 2.2.1. or 2.2.2. They can violate both SCs because both SCs describe different problems and have different user groups in mind.

• 2.2.1: Users need more time to read content and perform tasks. ("The intent of this Success Criterion is to ensure that users with disabilities are given adequate time to interact with Web content whenever possible. People with disabilities such as blindness, low vision, dexterity impairments, and cognitive limitations may require more time to read content or to perform functions such as filling out on-line forms")
• 2.2.2: Animated content can be distracting ("The intent of this Success Criterion is to avoid distracting users during their interaction with a Web page. ... One use of content that blinks is to draw the visitor's attention to that content ... For certain groups, including people with low literacy, reading and intellectual disabilities, and people with attention deficit disorders, content that blinks may make it difficult or even impossible to interact with the rest of the Web page.")

Both of these apply to carousel. A carousel that I can't stop is a violation of 2.2.1 and 2.2.2.

[jake-abma]

Hey @JAWS-test I agree, but if so, how can a carousel starting on page load (the first timing of the first slide) pass 2.2.1?

If the time limit starts right away, there's no "before encountering it;", often no 20 seconds to extend, and for sure they don't last 20 hours... :-)

so if applicable, probably fail ALL carousels for 2.2.1, unless the Understanding document needs adjustment, and/or the time limit to be defined when it kicks in.

[JAWS-test]

In a carousel, I usually have unlimited time to find the stop button and stop it. Thus no violation of SC 2.2.1. If there is no stop button, it would be a violation of 2.2.1. Or if I can stop the carousel, but then not change to the next view in the carousel: also violation of 2.2.1.

The difference between a carousel and an automatic logout is that with a carousel the information is not irreversibly lost if I cannot immediately extend the time limit.

A special case would be if new content is constantly displayed in the carousel, i.e. the first view cannot be displayed again. Then I would also consider it a violation of 2.2.1, if the stop button cannot be reached before the first view change. But I have never seen such a carousel before

[bruce-usab]

@JAWS-test certainly a carousel could violate more than one SC.

@jake-abma yes, I appreciate that we are using carousels as an example (to stress-test the SC). If a (well designed) carousel provides a pause functionality, I think you would agree that there is no accessibility barrier in actual practice. I admit that that the first two bulleted options (turn off / adjust) are only vaguely applicable because of the before encountering it condition. It think the third option (extend) is applicable, but only with a tortured reading (that I would rather not go into).

@jake-abma can you please propose a change to 2.2.1 text or Understanding, so you could say with a clear conscience that WCAG2 does not require that carousels fail 2.2.1 (unless they maybe start paused)? Thank you.

Edit: What I think I am asking for is maybe a note to the SC or adding a definition for time limit that is set by the content because I don't think 2.2.1 is even applicable to a typical carousel. But as you know, edits to Understanding are easier/faster to move forward.

[awkawk]

@JAWS-test I would disagree that not being able to advance the carousel after stopping it is a 2.2.1 failure. If the carousel can be stopped and not advanced that would impact any user that stops the carousel. This might be a gap in WCAG, but I think that authors generally want people to view the content so I haven't seen too many carousels that you can stop and not advance. The SC just talks about stopping. If the advancing was only available for mouse users then that would be a 2.1.1 issue.

[JAWS-test]

@awkawk

I would disagree that not being able to advance the carousel after stopping it is a 2.2.1 failure... This might be a gap in WCAG

This indeed seems to me to be a gap in WCAG. Conceivable would be a form, which is automatically sent after 1 min. I can disable the automatic submit to comply with SC 2.2.1. If I have stopped the auto-submit, there is no way to submit the form. This would be a serious problem, which is currently not covered by any WCAG SC

[jake-abma]

@JAWS-test says:

In a carousel, I usually have unlimited time to find the stop button and stop it. Thus no violation of SC 2.2.1.

I agree, IF the SC was not saying:

The user is allowed to turn off the time limit before encountering it

The lime limit starts directly (not that the user activates the time limit) so you will have unlimited time to find the stop button while the time limit is already running NOT before encountering the time limit, that was my issue.

As a prove of the time limit running is the last bullet: 20 Hour Exception: The time limit is longer than 20 hours. (so when it starts till the end, a time frame)

[JAWS-test]

@jake-abma

There are some examples in the Understanding which are very similar to a carousel and which show that it is sufficient to include a stop button:

A Web page has a field that automatically updates with the latest headlines in a rotating fashion. There is an interactive control that allows the user to extend the length of time between each update to as much as ten times the default. The control can be operated with either a mouse or a keyboard.

A Web page includes an animation which includes text that appears and disappears throughout. In some cases, the text is scrolling across the screen and in others, it is only displayed for a short time before it fades into the background. The page includes a pause button so that users who have trouble reading the text before it disappears can read it.

[jake-abma]

Hey @JAWS-test feels like we're running in circles here... :-)

Please try to see / re-read my issue, it's like: The SC text is telling a carousel must be red, in the Understanding is says, a green carousel. This means OR the Understanding document needs correction, OR the SC must be adjusted.

Based on another of your comments about having enough time to stop a carousel... When the slide changes after 5 second and you did not have time enough to to read it, the possibility to stop the carousel MUST happen 'before the time limit', so before second 1 of 5 before the slide swap. (That more slides appear after 5 seconds is not an escape to says: there's more time to stop the carousel...)

This is the issue.

Best way would be to change the SC text but that's the hardest thing for WCAG, something like like:

Turn off: The user is allowed to turn off the time limit before it is finished; or

OR

Turn off: The user is allowed to turn off the time limit before encountering the end of the limit; or

OR

Add a definition that the time limit is only the end of the time span

BUT you need to change the last bullet to something like:

20 Hour Exception: The time span before the time limit is longer than 20 hours.

[JAWS-test]

@jake-abma I don't think that a time limit has a beginning, but only an end and that "before" is not meant spatially, but temporally. I can press the stop button in carousel before the first view change. So I don't think the SC needs to be adjusted. And in the Understanding it is explained how to understand the SC. I don't see that the SC contradicts the Understanding

[jake-abma]

@JAWS-test again, circles... :-)

Last bullet: The time limit is longer than 20 hours. is that "an end"? 20 hours?

[jake-abma]

also, the Understanding is talking about "customize the length of time limits" how can you do that if is has no beginning and end? You can customize the end point, sure (or basically the time span before the end)

So it contradicts / blends the end point with the time span, as mentioned multiple times.

[jake-abma]

ps. when no definition is defined we use Webster Dictionary:

Definition of time limit : an amount of time in which something must be done or completed (so beginning till end!)

https://www.merriam-webster.com/dictionary/time%20limit

[JAWS-test]

@jake-abma A carousel can stand still and then start automatically after 10 minutes. The change between 2 views takes place every 5 seconds. Does the extension of time have to happen within the 10 minutes or before 10 minutes + 5 seconds? If it must be done already within the 10 minutes (before the start of the time limit), then this is impossible for most time limits, because they start when the page is loaded. Therefore I assume that the SC means: before the end of the time limit and not before the start.

[bruce-usab]

@jake-abma from your Webster definition, an amount of time in which something must be done or completed, WRT typical carousel behavior the amount of time is unbounded. There is not a lime limit. SC 2.2.1 is not applicable.

Please suggest an edit that would address the ambiguity which you perceive.

[jake-abma]

@bruce-usab there is a time limit before going to the next slide, while people didn't have time to read it

[bruce-usab]

there is a time limit before going to the next slide

Okay, I finally understand where you are coming from! Thank you! Sorry to be so dense!

My perspective on this issue, and my request to you remains the same. SC 2.2.1 is not (typically) applicable to (typical) Carousels. What is an edit which would remove any ambiguity about that?

[awkawk]

I would disagree that not being able to advance the carousel after stopping it is a 2.2.1 failure... This might be a gap in WCAG

This indeed seems to me to be a gap in WCAG. Conceivable would be a form, which is automatically sent after 1 min. I can disable the automatic submit to comply with SC 2.2.1. If I have stopped the auto-submit, there is no way to submit the form. This would be a serious problem, which is currently not covered by any WCAG SC

This would be a problem for everyone, so wouldn't be covered by WCAG.

[JAWS-test]

@awkawk

This would be a problem for everyone, so wouldn't be covered by WCAG.

I don't understand that argument. Any time limit can become a problem for everyone. But since people with certain impairments need more time to read or operate, there is SC 2.2.1.

If the carousel can be stopped and not advanced that would impact any user that stops the carousel.

That's why I think SC 2.2.1 indirectly requires me not only to be able to stop the carousel, but also to be able to continue it. A carousel consists of different views, each with its own time limit, 10 seconds for example. If I stop the first view, I have fulfilled SC 2.2.1 for it. But if I cannot continue, then I have not fulfilled SC 2.2.1 for the second view. Because I have not seen the second view for 10 seconds, but only for 0 seconds - i.e. the time limit has not been extended (as required by SC 2.2.1) but reduced to 0.

[awkawk]

@JAWS-test It is a bit of a forced example - I've never seen a form that auto-submits, and of course every person would want to pause the auto-submit, and then not being able to submit it is a problem for everyone and not a WCAG issue.

The idea of a carousel that once stopped, can never be restarted, is only slightly more likely. People create carousels to pack more content into a small or featured space on a web page, so the idea that a carousel is going to prevent people from looking at all of the steps is unlikely. As the WG didn't see this as a real-world issue, it didn't specify that there needs to be a way to advance the carousel. Sure, it could be an issue, but is it enough of an issue that it needs to be evaluated on every web page that is trying to conform with WCAG? I don't think that the group thought it was.

[alastc]

Just from skimming this issue, does anyone want to propose an update to the understanding document?

[bruce-usab]

I am happy to volunteer to propose an up updated to the Understanding document.

@jake-abma my proposed edit will be from the perspective of clarify that 2.2.1 is not applicable to things like Carousels. Are you okay with that?

[jongund]

Are you aware of the Carousel Design Pattern and Examples in the ARIA authoring practices?

[bruce-usab]

Thank you @jongund for bringing that doc to my attention, as it was not on my radar. I had only planned to double check Understanding against the wai tutorial (mentioned above).

@jongund do you agree that, generally, that 2.2.1 is not applicable to typical carousel behavior? Or is it your considered opinion that 2.2.1 is applicable to typical carousels behavior, and since carousel initial state is not paused, most every carousel fails against 2.2.1?

Edit to note that ARIA authoring practices pattern and examples (that Jon pointed out) also does not event hint that 2.2.1 is applicable to carousels. The very nice (live, working) examples included do not start paused, and would fail against the choices provided by 2.2.1 (were those choices applicable [but they are not, so no problem]).

[jake-abma]

Hi @bruce-usab sorry, a little late, but yes, that would be fine! Thx

[bruce-usab]

Thanks @jake-abma, your feedback is much appreciated and perfectly timely. I do hope to put in a PR by the end my business day then.

[bruce-usab]

My proposed fix is to add a paragraph towards the very end of Intent:

This success criterion is generally not applicable when the content repeats or is synchronized with other content, so long as the information and data is adjustable or otherwise under the control of the end user. Examples of time limits for which this success criterion is not applicable include scrolling text that repeats, captioning, and carousels. These are situations do include time limits, but not time limits that are set by the content, because access to the information and data is not limited any meaningful way by time aspect of the content.

It is a little bit more hand waving than I would like because (as @jake-abma tried at the start to explain to me) the Understanding doc clearly articulates that the term time limit does cover the time needed to read text (in a carousel) before the carousel moves onto the next item.

Should we ever get to revisit 2.2.1, the better fix IMHO would be to put some scoping limitations around before encountering it condition of the first two bullets.

[JAWS-test]

@bruce-usab I find the suggested wording difficult to understand. I would rather emphasize that the criterion also applies when the content repeats or is synchronized with other content, but it is fulfilled if the content can be stopped and started.

[bruce-usab]

@JAWS-test please suggest what phrasing you would like for us to have, and if it is a change to the SC or Understanding.

I agree with you that being able to stop the content addresses the accessibility barrier, but allowance for that is not provided for within the text of the (current) SC. The way out of this conundrum is to conclude that 2.2.1 does not apply to carousels. That is the rational I am focused on.

[jongund]

@bruce-usab The factors in the APG examples if the carousel is auto-rotating when the page is loaded are that there must be a mechanism for a screen reader user to be aware of the carousel and to be able to pause the rotation in both interactive and review modes of the screen reader. The carousel information and the pause control must before the changing carousel content in DOM order. In addition focus and hover events in the carousel also pause automatic rotation.

[JAWS-test]

@bruce-usab

• Since the SC cannot be changed, my comment refers to the Understanding (as does yours)
• Stopping is just one (and the best) example (for carousels). Required for scrolling text that repeats, captioning, and carousels is, in my opinion, one of the many conditions under SC 2.2.1. However, it would be wrong to say that none applies. A carousel can e.g. only change the view every 20 hours, or offer a possibility to stop and go, or the user can increase the time of the view change tenfold, or the user is warned before every view change and has 20 seconds to stop it.

[jongund]

@bruce-usab Another feature of the Carousel examples in the ARIA APG is testing if the user has chosen "reduced motion" in the operating system settings. When "reduced-motion" is enabled, the auto-rotation will always be paused on load.

[bruce-usab]

Thanks @jongund, that is pretty slick.

@JAWS-test as written, IMHO, the position has to be that 2.2.1 is not applicable to repeating content like Carousels. To say otherwise would be to say that AGWG has overlooked this for years., and all the great WAI (and elsewhere) guidance about Carousels is grossly insufficient (because those materials do not cite to 2.2.1). Carousels (and the like) starting off animated is not an accessibility barrier. I acknowledge that argumentum ad consequentiam is a classic logic fallacy, but I can live with that! I agree that stopping the Carousel is the best example for carousels, and accessibility guidance can be expected to stress that feature, but such a feature is not sufficient for 2.2.1 unless the stop is before encountering it (but no one does that for Carousels [except maybe with Jon's example immediately above] and its not a problem for accessibility).

[JAWS-test]

@bruce-usab I do not think it is problematic to add 2.2.1 to https://www.w3.org/WAI/tutorials/carousels/

[bruce-usab]

@JAWS-test i respectfully disagree. It opens a whole can of worms.