← All criteria
2.2.1Level AWCAG 2.0Guided or hands-on fix

Timing Adjustable

Time limits set by the content must be adjustable: users must be able to turn off, adjust, or extend any time limit before encountering it.

What it requires

WCAG 2.0 SC 2.2.1 covers session-timeouts, countdown sale offers, time-limited form submissions, and any other timing constraint imposed by the website. Users must be able to turn off the time limit, extend it (at least 10× the default), or be warned with a chance to extend before the limit triggers.

Exemptions: real-time competitive events, time limits essential to the activity (e.g. an auction closing), and time limits longer than 20 hours.

Common Shopify failure

Cart that holds reserved inventory for 5 minutes with no warning before clearing. Flash-sale checkout countdown with no extension option for users who need more time to enter address details.

How to fix it

Provide a standards-appropriate way to turn off, adjust, or extend the time limit, or document why an exception applies. Inventory and checkout timing rules require product and legal review before changing behavior.

Merchant QA checklist

  • Scan the storefront page where this pattern appears: product pages, collection pages, cart drawer, customer-account pages, and any landing page built with theme sections.
  • Confirm the issue is fixed in the rendered browser output, not only in the Liquid file. Shopify section settings, app blocks, and third-party scripts can reintroduce the same 2.2.1 failure after a theme edit.
  • Re-test the affected component with keyboard navigation and a screen-reader accessibility tree before publishing the theme, especially when the fix changes markup or ARIA attributes.

How AccessComply handles it

AccessComply uses automated rules to check supported patterns in the pages reached during a scan. Some WCAG requirements need human judgment, assistive-technology testing, or access to third-party content and cannot be established by an automated scan. This criterion is generally treated as a guided or hands-on fix pattern. If the app can safely match the issue to supported source code, the merchant must review and approve the suggested change before anything is written, and the result is checked afterward. Otherwise the merchant should use the guidance above and independent hands-on testing. The label is not a guarantee of detection, a fix, WCAG conformance, or legal compliance.

Primary source: W3C — WCAG 2.0 Understanding 2.2.1