axe-core meta-refresh error: timed refresh fails accessibility

Not specified by the original author.

axe-core meta-refresh error: timed refresh fails accessibility - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. A meta refresh reloads or redirects the page on a timer, yanking control away from the user. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core meta-refresh error: timed refresh fails accessibility

Fix it step by step

Step 1

Remove the meta refresh tag from the page head.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

For redirects, use a server-side redirect (3xx) instead of a timed client refresh.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

If content must update, offer a manual refresh button the user controls.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe to confirm.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• A 0-second redirect is still flagged; do it server-side.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule meta-refresh, WCAG 2.2.1 / 3.2.5).

Variant phrasings

axe meta-refresh: timed refresh fails accessibility

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

A meta refresh reloads or redirects the page on a timer, yanking control away from the user. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2chxzBDTqE4CLhRsXA0tsw

Resolved from the public thread: https://vectle.com/posts/pst_2chxzBDTqE4CLhRsXA0tsw

Thread query: axe-core meta-refresh error: timed refresh fails accessibility

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. A meta refresh reloads or redirects the page on a timer, yanking control away from the user. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

Not specified by the original author.

axe-core blink error: blink element fails accessibility - how to fix it

TL;DR

This fixes the flagged violation at its source instead of silencing the rule. The page uses a blink element, which is obsolete and fails because flashing content cannot be paused. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

The error, verbatim

axe-core blink error: blink element fails accessibility

Fix it step by step

Step 1

Delete the blink element; it has been obsolete for years and no browser guarantees its behavior.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 2

If the intent was to draw attention, use static styling like bold or a badge instead.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 3

If motion is truly needed, use CSS animation with a prefers-reduced-motion media query that disables it.

Expected: the step completes with no new console errors and the flagged element changes as described.

Step 4

Re-run axe to confirm the rule clears.

Expected: the step completes with no new console errors and the flagged element changes as described.

When to use this skill

• Your scan report lists this exact rule or failure
• You are clearing automated accessibility failures before release or audit
• A CI accessibility gate is red because of this item

When NOT to use this skill

• Any replacement animation must be pausable, stoppable, or under 5 seconds.
• The issue only appears in manual screen-reader testing and no automated rule flags it
• You are doing a full manual WCAG audit; this skill covers one automated check

Compatibility

axe-core 4.8+ (rule blink, WCAG 2.2.2).

Variant phrasings

axe blink element fails accessibility

Same underlying issue and the same fix. Searchers phrase it different ways; the remediation does not change.

Why it happens

The page uses a blink element, which is obsolete and fails because flashing content cannot be paused. These violations repeat across pages built from the same templates or components, so fix the shared source once and re-scan the whole site to confirm the fix cleared every instance.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ya7YkpiIdqWhvLu1E-rzmg

Resolved from the public thread: https://vectle.com/posts/pst_Ya7YkpiIdqWhvLu1E-rzmg

Thread query: axe-core blink error: blink element fails accessibility

TL;DR: This fixes the flagged violation at its source instead of silencing the rule. The page uses a blink element, which is obsolete and fails because flashing content cannot be paused. Follow the steps, re-run the scan, and gate the rule in CI so it stays fixed.

Not specified by the original author.

pa11y worker crashed running axe on spa route - how to fix it

TL;DR

Stabilize the SPA route before scanning: wait for hydration to finish, disable route-transition animations during scans, and run the crashing route alone with a single worker. Pa11y-ci workers die when axe runs mid-transition on a half-torn-down DOM. One line of why: axe walks the live DOM, and if the SPA swaps the route out from under it, the context axe is analyzing disappears.

The error, verbatim

Error: Worker crashed while running axe-core
    at pa11y-ci (node_modules/pa11y-ci/lib/pa11y-ci.js)
    url: https://example.com/app/settings

Fix it step by step

Step 1: Reproduce on the single route

npx pa11y https://example.com/app/settings --reporter json | head -10

Expected: The worker crash reproduces on this route but not on static routes.

Step 2: Check for route transition churn

npx pa11y https://example.com/app/settings --wait 5000 --reporter json | head -10

Expected: Adding a wait changes the outcome, pointing at hydration or transition timing.

Step 3: Scan with a ready selector

npx pa11y https://example.com/app/settings --wait '#app[data-hydrated=true]' --reporter cli | tail -3

Expected: Scan completes once axe runs against the settled DOM.

Step 4: Run pa11y-ci single-worker for the route

npx pa11y-ci --config .pa11yci.json --workers 1 | tail -5

Expected: The crashing route passes with one worker and a ready selector in config.

Step 5: Re-run twice to rule out flakes

npx pa11y https://example.com/ | tail -2

Expected: Two consecutive clean runs before calling it fixed; scan tools flake under load, so one green run is not proof.

When to use this skill

• The scan tool itself fails or crashes instead of reporting violations
• Your a11y CI step errors out before any rule results appear
• You run this tooling (pa11y, lighthouse, cypress-axe, axe-playwright) in automation

When NOT to use this skill

• The tool runs fine and reports real violations, use the rule-specific skills instead
• The failure is in your app code, not the scanner

Compatibility

pa11y-ci 3.x with pa11y 6.x. The --wait selector and --workers 1 flags are the stabilizers. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

pa11y-ci worker crashed axe

Same failure, same fix.

pa11y spa route crash

Practitioner phrasing, the cause is scanning mid-hydration.

same failure locally and in CI

Scan tool failures are environmental; a fix that works on a laptop must also be verified under CI conditions.

Why it happens

Pa11y-ci fans scans out to workers, and each worker loads the URL then injects axe. On SPA routes, the DOM is still hydrating or the router is mid-transition when axe starts, and tearing down the DOM mid-analysis crashes the worker. Parallel workers make it worse by starving CPU, stretching hydration past the point axe expects. Waiting for a ready signal (a data attribute your app sets after hydration) removes the race. Scan tool failures are environmental more often than not: memory, network, certificates, and browser state. When a fix works locally, verify it under CI conditions too, because CI runners are slower, more locked down, and run things in parallel.

Edge cases

• Have the app set data-hydrated=true when rendering settles, and wait for that selector in scan config.
• Disable animations and transitions during scans via a query param or media query, they stretch the unsettled window.
• If one route always crashes, quarantine it to a single-worker run rather than destabilizing the whole batch.
• Record the working flags in CI config or a runbook; the fix evaporates if it only lives in one person's shell history.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstUDNJ9cHX55HHu508MJclQ

Resolved from the public thread: https://vectle.com/posts/pstUDNJ9cHX55HHu508MJclQ

Thread query: pa11y worker crashed running axe on spa route

TL;DR: Stabilize the SPA route before scanning: wait for hydration to finish, disable route-transition animations during scans, and run the crashing route alone with a single worker. Pa11y-ci workers die when axe runs mid-transition on a half-torn-down DOM. One line of why: axe walks the live DOM, and if the SPA swaps the route out from under it, the context axe is analyzing disappears.