For each web page, does the user have control over each time limit that modifies content (except in special cases)?
A user with cognitive disabilities is filling out a social assistance request form. Their session expires after five minutes, without warning, without the ability to extend it. They lose everything and don't understand what happened. This criterion exists for them.
Criterion 13.1 covers three situations: automatic page refreshes (via <meta http-equiv="refresh"> or embedded elements like <object>, <svg> or <canvas>), automatic script-initiated redirects with delay, and session expirations after authentication. In each case, the user must be able to control the delay.
Four solutions are accepted: allow the user to stop and restart the limit, allow them to multiply it by 10 at minimum, warn them at least 20 seconds before expiration with the option to extend, or set the limit to a minimum of 20 hours. Only one is needed.
The "essential limit" exception is often invoked incorrectly. It only covers situations where removing the limit would fundamentally change the nature of the activity. A dashboard refreshed every hour? Not essential. A real-time auction? Essential.
4 tests to verify that each time limit is controllable
Mechanism to control automatic refreshes
- Identify all automatic refreshes in the page:
<object>,<embed>,<svg>,<canvas>elements, or<meta http-equiv="refresh" content="[number]">in the<head>. - For each refresh found, verify that at least one of these conditions is met: a. A mechanism allows the user to stop and restart the refresh. b. A mechanism allows multiplying the interval by 10 at minimum. c. A mechanism warns the user at least 20 seconds before the refresh and allows them to extend. d. The interval between two refreshes is at least 20 hours.
- If no condition is met for at least one detected refresh, the test fails.
Immediate redirection via <meta http-equiv=refresh>
- Locate in the
<head>a<meta http-equiv="refresh">element used as a redirect to another URL. - Verify that the value of
contentstarts with0(redirect without waiting time). - If the redirect is immediate (
content="0;URL='...'")), the test is validated. If a delay is present (content="5;URL='...'"for example) without a control mechanism, the test fails and the situation falls under test 13.1.1.
Mechanism to control automatic redirects by script
- Identify automatic redirects triggered by JavaScript: look for patterns
setTimeout(() => { window.location.href = '...' }, ...)or pages displaying a visible countdown before redirect. - For each detected redirect, verify that at least one condition is met: a. A mechanism allows the user to stop and restart the redirect. b. A mechanism allows multiplying the delay by 10 at minimum. c. A warning appears at least 20 seconds before the redirect, with the option to extend. d. The delay before redirect is at least 20 hours.
- If no condition is met for at least one redirect, the test fails.
Mechanism to control or minimum duration of session timeout
- Identify session timeout mechanisms in the page: personal spaces after authentication, multi-step protected forms, business interfaces.
- For each timeout detected, verify that at least one condition is met: a. A mechanism allows the user to remove the limit (for example, a "stay logged in" checkbox). b. A mechanism allows the user to increase the session duration. c. The session duration is at least 20 hours by default.
- If no condition is met, the test fails. If the timeout is essential in the strict sense (activity fundamentally altered without it), the criterion is not applicable.
Examples
❌ Non-compliant : Automatic refresh without any user control
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="refresh" content="120" />
<title>Dashboard - Statistics</title>
</head>
<body>
<h1>Real-time Statistics</h1>
<p>This data is updated automatically.</p>
<!-- No button to stop or defer the refresh -->
</body>
</html>The page reloads every 2 minutes without the user being able to prevent it. A screen reader reading the content is interrupted abruptly and repositioned at the top of the page. A user who had filled in a search field loses their input. For users with slow connections, the reload may trigger before the previous page is even readable.
✅ Compliant : Session timeout with warning and extension button
<div id="session-warning"
role="alertdialog"
aria-labelledby="session-title"
aria-describedby="session-desc"
aria-modal="true"
hidden>
<h2 id="session-title">Your session is about to expire</h2>
<p id="session-desc">
You will be logged out in
<span id="countdown" aria-live="off">60</span> seconds
due to inactivity.
</p>
<button type="button" onclick="prolongSession()">
Extend my session by 20 minutes
</button>
<button type="button" onclick="logOut()">
Log me out now
</button>
</div>The dialog opens at least 20 seconds before expiration. The alertdialog role ensures that screen readers announce it immediately, without waiting for the user to navigate to it. The extension button works without page reload. Test 13.1.4 is validated and WCAG 2.2.1 criterion (level A) is satisfied.
Tips and pitfalls
⚠️ Confusing "security reason" and "essential limit"
A 10-minute session timeout for security reasons is not an "essential limit" in the RGAA sense. Security is a business constraint, not a technical impossibility to extend. The standard solution: display a warning 20 seconds before expiration with an extension button. Security is preserved, accessibility too.
⚠️ Immediate redirect via <meta refresh> is compliant without control mechanism
An element <meta http-equiv="refresh" content="0;URL='https://example.com/new-url'" /> redirects instantly, without perceptible delay. This is the subject of test 13.1.2: if the redirect is immediate (content="0"), no control mechanism is required. However, content="5;URL='...'" (five-second wait) is subject to the same requirements as any other automatic refresh.
💡 The 20-second warning: the most versatile solution for sessions
For session timeouts, this is the most common and simplest mechanism to deploy. Use role="alertdialog" so screen readers announce it upon appearance. The extension button must work without re-authentication. Audit tip: test this dialog with keyboard only, without mouse, to verify it is fully accessible.
⚠️ The <object>, <embed>, <svg> and <canvas> elements are also affected
Test 13.1.1 is not limited to <meta http-equiv="refresh">. A <canvas> element animated by JavaScript that reloads its data every 30 seconds falls under the same criterion. In audits, do not check only the <head> of the page: also inspect the scripts associated with embedded elements.
⚠️ RSS feeds, dashboards, stock prices: not essential by default
The RGAA explicitly cites RSS feed as an example of a non-essential refresh. Same for a dashboard with statistics updated every minute or a stock ticker with delayed data. The "essential" exception is strictly reserved for cases where removing the limit would destroy the functionality itself: live auctions, timed exams, or redirects from obsolete URLs to their current version. When in doubt, apply the criterion.
Frequently asked questions
Why is a carousel with automatic scrolling subject to RGAA criterion 13.1?
It is not. Carousels and looped animations fall under criterion 13.8 (pause, stop, hide), not 13.1. Criterion 13.1 specifically addresses time limits that reload the page, redirect the user, or expire a session. These are two distinct issues with two distinct criteria.
How to make automatic disconnection after 30 minutes of inactivity RGAA 13.1 compliant?
Implement a role="alertdialog" that appears at least 20 seconds before disconnection, with a session extension button. This button must work without full page reload and without requiring the user to re-authenticate. This approach validates test 13.1.4 and satisfies WCAG 2.2.1 criterion (level A). The extension duration is not mandated by RGAA: 20 minutes is a common and reasonable value.
How to audit a session timeout that is not visible in the source code?
Three complementary approaches: naturally wait for the session to expire (15 to 30 minutes of inactivity), monitor network requests to detect session check calls and their frequency, or directly ask the technical team for the configuration. In RGAA audit, if the timeout is confirmed and no warning appears, the criterion is non-compliant.
When is an automatic redirect to an obsolete URL compliant with RGAA criterion 13.1?
Yes, it is the exact example cited by RGAA for the "essential limit" exception: the criterion is not applicable. Redirect from an obsolete URL is an infrastructure fix, not a design choice. On the other hand, if it is a waiting page after login that redirects to a dashboard, it is not essential: use an immediate redirect (content="0") or a control mechanism.
What minimum session duration makes RGAA criterion 13.1 compliant without additional mechanism?
Yes: 20 hours. If the session lasts at least 20 hours by default, no extension mechanism is required (test 13.1.4, condition c). The same rule applies to automatic refreshes: an interval of 20 hours or more satisfies tests 13.1.1 and 13.1.3 without any control interface. In practice, few applications reach this threshold, so the warning dialog solution remains the most realistic path.