Success Criterion 2.2.1 - Timing Adjustable - Level A

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#timing-adjustable

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

[qbalsdon]

I think this can be kept as is

[JJdeGroot]

MATF meeting on July 31, 2024

[Source](https://www.w3.org/2024/07/31-matf-minutes.html#t04) JJ: Reading the WCAG2ICT description, mentioning that toasts/snackbar on Android are common failures because they only show for a couple seconds. I have this somewhere, but should we mention examples where system settings allow for this, and should we give guidance on doing it in app or surfacing from settings? +1 to @JJ to clarify how this timing adjustable applies to toast/ snackbar or future other components/ alerts as a general concept +1 for guidance on "system" level things like snackbars [ACTION: Github issue for dealing with system settings when testing (toast length, high contrast mode, etc.)](https://github.com/w3c/matf/issues/64) julianmka app makers should meet requirements without system settings being required +1 to developer responsibility without system settings adding more settings doesn't solve that either Quintin can you provide a link to the timing developer technique you mentioned? But I do agree that we should not rely on OS manufacturers Sure Joe, after scribing :) I found it quickly Joe_Humbert: https://support.google.com/accessibility/android/answer/9426889?sjid=18325240353724858189-EU Jamie: Users do expect system settings to be applied throughout apps thank you Quintin Joe_Humbert I can send you adb commands and where it exists in the ecosystem as well - if you like, but after :) +1 Jamie Agree - developers should respect system settings, and if those settings are not set, then provide an accessible experience out of the box Jamie system settings should form a baseline expectation, but developers maintain responsibility for their app

Summary:

quintinb suggests mentioning examples and guidance for using system settings in apps. JJ acknowledges this and assigns an action to create a GitHub issue to address system settings during testing.

julianmka and Jamie support clarifying timing adjustments for components like toast/snackbar. quintinb emphasizes that app makers should meet requirements without relying on system settings, and adding more settings isn't a solution.

Joe_Humbert agrees with this responsibility and requests a link to the timing technique, which quintinb provides, offering further information later.

Jamie notes user expectations for system settings across apps, and julianmka agrees, stressing that developers should respect these settings and ensure accessibility out of the box. Jamie concludes that system settings should be a baseline, but developers remain responsible for their app's accessibility.

[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.2.1, replacing “the content” with “screens or views”.

With this substitution, it would read:

2.2.1 Timing Adjustable: For each time limit that is set by [screens or views], at least one of the following is true:

• Turn off: The user is allowed to turn off the time limit before encountering it; or
• Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
• Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and the user is allowed to extend the time limit at least ten times; or
• Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
• Essential Exception: The time limit is essential and extending it would invalidate the activity; or 20 Hour Exception: The time limit is longer than 20 hours.

NOTE

This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.

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

[JJ]

Thanks for the great work, but you keep using my nick instead of the one by @JJdeGroot. I have already unsubscribed from several issues, but I would be grateful if you avoided doing it again in the future. Thanks!

[JJdeGroot]

A few notes/comments below from e-mail conversation with @alastc (AC)

JJ: For 2.2.1 Timing Adjustable, the user is able to adjust some timing related settings at the system level on Android and iOS

• Is this an acceptable "mechanism"? Note 1 in the definition mentions: "The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies."
• This not only includes user agents, but also the platform, in this case Android and iOS; therefore it's a sufficient technique to conform?
• But... users might not be aware of such system settings, because they can be buried multiple levels deep

AC: I’m a bit confused, do you mean for 2.2.2 Pause, Stop, Hide? 2.2.1 doesn’t mention a mechanism. If there were a system level thing that allowed users to turn-off/adjust/extend, I think that could be used.

JJ: Sorry, the note is indeed for 2.2.2. There is a system setting on new Android versions to increase the time limit of toasts.

AC: In which case, I think you could allow for a system level thing that allowed users to turn-off/adjust/extend.

JJ: Okay, the question is when is a setting considered widely-available? Would auditors need to write this down in the "Accessibility support baseline" section? E.g. some settings are only available on newer Android version, and some settings be buried deep in the settings screens.

AC: In WCAG 2.x we’ve taken that on a case by case basis but, for example, a system setting is sufficient to pass Animation from interactions in C39. This sounds similar.

This topic is a constant discussion, there isn’t a clear and concrete answer for a world-wide standard. However, if the setting is free (once the base device and OS are paid for), and on more than 66% of used devices it should be a fairly safe option.

[julianmka]

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

[detlevhfischer]

@julianmka @alastc One thing to keep in mind apart from the question whether coverage / availability of such system setting is wide enough across the base of installed systems:

The Android setting warns that it is not supported by all apps, which would mean that at test procedure would need to check whether activating the setting indeed allows to adjust the time - meaning the testing of toast messages cannot be dismissed summarily by saying "well, there is a system setting for adjusting that now".

[julianmka]

Great point, @detlevhfischer. And, for what it's worth, I fall into the camp of "don't rely on system settings alone" for the reasons you've shared previously. So many users aren't aware of their options and sometimes there's spotty support as in your Android toast example. I think solely relying on system settings is a bit of a cop-out.

As @alastc pointed out, taking these things on a case-by-case basis may be the way to go: font size settings are universal in the native mobile landscape and it would be redundant for an app to offer its own font size setting instead of or in addition to supporting the system-level preference. On the other hand, extending the time that a toast is shown onscreen is much less widely supported, so the responsible thing for an app publisher to do is account for longer toast appearance times in their app. (Whether they do it through an app-level setting or persist toasts until dismissed or some other conformant approach.)