New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Carousels fail 2.2.1: Timing Adjustable ?! #1658
Comments
Also the example...
... 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. |
The example...
... is also contradictory as it suggests "before it disappears" and NOT "before encountering it" |
Same for example: https://www.w3.org/WAI/WCAG22/Techniques/general/G198 Should "before" be replaced with "when"? |
I'm not sure I understand your question correctly. I suspect the following:
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 |
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. |
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. |
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. |
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... |
@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. |
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 |
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. |
Hi @bruce-usab see the Understanding:
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. |
@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/ |
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. |
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:
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:
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?
I would say, check, check, check, check, check, but I might be missing something and would love to hear it. Cheers! |
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.
Both of these apply to carousel. A carousel that I can't stop is a violation of 2.2.1 and 2.2.2. |
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. |
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 |
@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 @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 |
@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. |
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 |
@JAWS-test says:
I agree, IF the SC was not saying:
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) |
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:
|
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:
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:
|
@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 |
@JAWS-test again, circles... :-) Last bullet: The time limit is longer than 20 hours. is that "an end"? 20 hours? |
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. |
ps. when no definition is defined we use Webster Dictionary: Definition of time limit |
@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. |
@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. |
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? |
Are you aware of the Carousel Design Pattern and Examples in the ARIA authoring practices? |
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]). |
Hi @bruce-usab sorry, a little late, but yes, that would be fine! Thx |
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. |
My proposed fix is to add a paragraph towards the very end of Intent:
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 Should we ever get to revisit 2.2.1, the better fix IMHO would be to put some scoping limitations around |
@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. |
@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. |
@bruce-usab |
|
@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 |
@bruce-usab I do not think it is problematic to add 2.2.1 to https://www.w3.org/WAI/tutorials/carousels/ |
@JAWS-test i respectfully disagree. It opens a whole can of worms. |
You wrote:
Conversely, this means that SC 2.2.1 is applicable if the information and data is not adjustable or is not under the control of the end user. If we should agree on this, then I merely suggest to formulate it in this way, because it is more understandable
|
Going back to the original post, it occurs to me that you do not need to consider carousels time limited. The content is still there, it will either be repeated, or you can use the controls to go back to a particular item. So I'd suggest a slight update to Bruce's text: 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 [ins]the content is still available to the user because it repeats or has controls for accessing it[/ins]. I think that lines up with the conversation? @bruce-usab I added your changes to the HTML version of the understanding doc, we don't use the XML versions any more. |
Looks good, thanks! But please double check that last sentence. Either delete
|
Maybe mention that while these situations don't fall under 2.2.1, they're likely falling under 2.2.2 Pause, Stop, Hide then. https://www.w3.org/TR/WCAG/#pause-stop-hide |
@patrickhlauke these situations are not likely failing under 2.2.2 because the context is carousels (et al.) that follow best practices. No harm mentioning that 2.2.2 is likely applicable to these situations, but I think the Understanding doc includes that detail. |
FWIW i wrote "falling", not "failing" |
I disagree that repeating (without being able to pause or slow down the presentation) is sufficient to satisfy 2.2.1. If text content scrolls quickly and I cannot pause it, it is impossible to read it when I am impaired. It would be ok with an AND instead of the OR:
|
2.2.1 is pretty clear about time limits, focussing on carousels which start playing on page load I read:
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:
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?)
The text was updated successfully, but these errors were encountered: