Automatic page refresh occurs when a page reloads or redirects on its own, without the user requesting it. When this happens without warning or user control, it can interrupt tasks, reset focus, and cause users to lose their place.
This issue most commonly occurs when the HTML <meta http-equiv="refresh"> element is used to refresh or redirect a page automatically, but the accessibility failure is loss of user control, not the technique itself.
WCAG Success Criteria
Automatic refresh and redirect behaviour can cause failures of multiple WCAG success criteria, depending on how it is implemented:
- SC 2.2.1 Timing Adjustable (Level A)
Users must be able to pause, stop, or extend time limits. - SC 3.2.5 Change on Request (Level AAA)
Changes of context must occur only when initiated by the user.
A failure occurs when refresh or redirect behaviour happens without user initiation and without a way to control timing.
Why This Matters
Unexpected refreshes and redirects disrupt how users interact with content:
- Keyboard focus is reset, often to the top of the page
- Screen readers restart reading from the beginning
- Users lose their position while reading or filling out forms
- Tasks may be interrupted or invalidated
For users who navigate sequentially, read slowly, or rely on assistive technologies, losing control over timing can make content unusable.
Intent of the Criterion
The relevant WCAG criteria intend to ensure that users control changes that affect timing and context.
Automatic refresh is not categorically forbidden. It becomes an accessibility failure when:
- The user did not request the change
- The change occurs after a fixed time limit
- The user cannot pause, stop, delay, or extend it
At higher conformance levels, particularly Level AAA, changes of context must occur only on user request.
Common Problematic Patterns
Accessibility issues often arise when <meta http-equiv=”refresh”> is used to:
- Periodically reload content
- Redirect users after a delay
- Automatically log users out
- Refresh dashboards or status pages
Example of problematic markup:
<meta http-equiv="refresh" content="40" url="http://www.yourdomain.com/index.html">In this pattern, the user has no control over when the refresh occurs.
Session Timeouts (Common Real-World Failure)
Automatic session expiration is a frequent source of WCAG failures.
Examples include:
- Silent logout after inactivity
- Redirect to a login page without warning
- Loss of unsaved form data
Session timeouts are timed interactions. Users must be warned and given a way to extend the session. Silent timeouts or forced redirects commonly fail SC 2.2.1, and often SC 3.2.5.
Recommended Fixes
Remove Automatic Refresh Where Possible
If refresh is not essential, remove the <meta http-equiv="refresh"> element entirely.
Use Server-Side Redirects
If the goal is navigation or redirection, use HTTP status codes (such as 301 or 302) instead of client-side refresh.
Even immediate refreshes (for example, content=”0″) can fail WCAG if they cause a change of context without user request. Server-side redirects avoid this risk.
Provide User Control for Timed Updates
If content must update automatically:
- Use JavaScript instead of meta refresh
- Clearly inform users that an update will occur
- Allow users to pause, stop, or extend the timing
User control must allow users to:
- Prevent the refresh entirely, or
- Extend the time before it occurs, and
- Continue their task without losing focus or data
A warning alone is not sufficient if users cannot act on it.
What This Does Not Mean
This guidance does not mean that:
- All page updates are forbidden
- JavaScript-based updates automatically fail
- Redirects are never allowed
Failures occur when timed changes remove user control or cause unexpected context changes.
Rule Description
Pages must not refresh or redirect automatically in a way that prevents users from controlling timing or causes a change of context without user initiation.
The <meta http-equiv="refresh"> technique frequently creates these conditions and should be avoided unless user control is explicitly provided.
The Algorithm
- Determine whether the page refreshes or redirects automatically
- Check whether the user requested the change
- Verify whether users can pause, stop, or extend the timing
- If the change occurs without user control or initiation, the criterion fails
Wrapping Up
Automatic refresh is not an accessibility feature; it is a risk. When pages refresh or redirect without user control, users lose focus, context, and progress. WCAG requires that users remain in control of timing and context changes, especially at higher conformance levels.
If users cannot prevent, delay, or initiate a refresh themselves, the design fails to meet accessibility expectations.
