In one paragraph
Delayed refresh under twenty hours identifies a positive meta-refresh delay within this rule's configured range. Automatic reloading or navigation can interrupt reading, discard work, or create an unadjustable time limit. Remove unnecessary timed changes and provide a suitable user-controlled alternative. An immediate redirect or a delay outside the checker range is not, by itself, proof that the whole experience satisfies WCAG timing requirements.
Why it matters
WCAG 2.2.1 gives several ways to address content-imposed time limits, including switching them off, adjusting them, or warning users with a meaningful extension opportunity. It also defines real-time, essential, and longer-than-twenty-hour exceptions. The specific exception must actually fit the task.
A meta refresh can change location or reload the document without a usable choice, potentially resetting focus or a form. A visible countdown alone does not make the limit adjustable. Security-related timing also needs analysis rather than an automatic blanket exemption.
A genuine immediate server redirect is different from giving someone a page and then removing it after a short reading interval. Choose navigation and status design based on the real need instead of changing an arbitrary number just to pass a rule.
How WebAuditOS evaluates this finding
The supplied meta-refresh implementation parses the leading delay on applicable refresh metadata. Zero passes; positive delays through 72,000 seconds fail; longer delays pass this check. Unreadable values can escape detection rather than being proved safe.
Critical impact maps to high severity. A short redirect may occur before the rendered scan reaches the original page, leaving it unreported. JavaScript timers, server-controlled session limits, and other timing mechanisms require additional review beyond this attribute test.
How to fix it
- Locate the actual refresh declaration and identify whether it reloads information, moves to a new page, or tries to enforce a session workflow. Check templates and generated headers or scripts separately.
- For a lasting URL move, use the appropriate server-side redirect directly to the relevant destination, and update internal references. Do not serve a reading page merely to navigate away seconds later.
- For new information, consider an explicit update action or a well-designed in-place update that preserves user control and task state. A button such as Check for updates still needs a working handler and useful feedback.
- For a genuine time limit, evaluate the WCAG options and exceptions carefully. An extension mechanism has specific warning, available-time, and repetition conditions; a fleeting toast is not automatically adequate.
- Preserve entered information and a meaningful recovery path when authentication expires, subject to appropriate security and privacy design. Do not disable essential safeguards without understanding the process.
- Check focus, scroll position, error messages, and partially completed tasks during updates. An apparently harmless reload can interrupt someone much later than your initial test.
- Test slow interaction, keyboard use, and supported assistive technology. Inspect both the first response and the final rendered location so a fast transition does not conceal the source of the change.
- Rescan and review other time-based changes manually. Do not replace a meta timer with the same unadjustable JavaScript timer and call the problem solved.
What the fix can break
Removing reload behaviour can leave information stale if the interface provides no replacement update path. Make freshness and update controls understandable.
Changing redirect status or destination can affect authentication and method handling. Choose the actual intended navigation semantics rather than applying one permanent code to every workflow.
A malformed value may stop a scanner reading the delay without preventing unwanted browser behaviour. Fix the design, not the parser's visibility.
Questions
Why can zero delay pass this rule?
It does not impose the same reading interval before navigation. That does not validate every other aspect of the destination or redirect chain.
Is a twenty-hour value automatically exempt?
The criterion's exception is for longer than twenty hours, and the supplied rule includes exactly 72,000 seconds in its failing range.
Does this rule detect every timeout?
No. Review sessions, scripts, disappearing opportunities, and other content timing separately.
Which related checks help?
Review redirect chains, moving content, and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared critical in axe-core 4.13.0, so a failure arrives as high - which is why the panel above states a conformance level rather than a severity.