Skip to main content

Accessibility Statement Caching Explained

AllAccessible uses performance caching to deliver your accessibility statement quickly to visitors worldwide. This guide explains how caching works, w

Written by Frank

Accessibility Statement Caching Explained

Overview

You saved a change to your accessibility statement, opened your site, clicked Statement in the widget, and the old text is still there. Nothing is broken. Your statement passes through three separate copies on its way to a visitor, and each one refreshes on its own schedule. This article explains where those copies live, how long each one lasts, how to force a fresh copy when you need to check your work, and when it is worth contacting support.

Who This Is For

  • Site owners who just edited their statement and cannot see the change yet

  • Agencies checking a client's statement after an update

  • WordPress plugin users who are not sure which "clear cache" button does what

  • Anyone who wants to know what "up to an hour" actually means

What You'll Learn

  • The three places your statement is stored and how long each copy lasts

  • Why "up to 60 minutes" is a worst case, not a fixed wait

  • How to force a fresh copy in your own browser

  • What the WordPress plugin's cache buttons do (and do not) clear

  • When to contact support

The Three Copies of Your Statement

1. Your dashboard copy (updates instantly)

When you click Save Statement on the site's Accessibility Statement page, the text is written to your account immediately. The Preview button on that page always shows exactly what you saved. If the preview is right, your save worked. Everything below is about delivery, not about whether the save "took".

Two things to know about the dashboard side:

  • Statement editing is available on paid plans with an active, trialing, or past-due subscription. On the free plan the page shows an upgrade prompt instead of the editor.

  • Each subdomain has its own statement. If your site is set up with more than one subdomain (for example www and shop), make sure you edited the one your visitors actually use.

📷 Accessibility Statement page with the Preview and Save Statement buttons highlighted

2. Our servers' copy (refreshes within 60 minutes)

When a visitor opens the statement in the widget, the widget asks our servers for the current text. To keep that fast, our servers hold a copy of each site's statement for up to 60 minutes after it was last fetched.

Saving in the dashboard does not clear this copy. So after a save:

  • If no visitor has opened your statement in the last hour, the server copy has already expired and the next visitor gets your new text right away.

  • If someone opened it recently, the old text is served until that copy expires, which is at most 60 minutes after it was last refreshed.

This is where "up to 60 minutes" comes from. The countdown starts from the last time a visitor fetched the statement, not from the moment you saved. On a busy site the practical wait is close to an hour; on a quiet site it is often zero.

3. The visitor's browser copy (does not expire on its own)

The first time a visitor opens the statement on your site, the widget saves the text in that browser's site storage so later opens are instant. That saved copy is used first, every time, and the widget does not currently put an expiry date on it.

In plain terms: a returning visitor who has already opened your statement keeps seeing the copy their browser saved until they clear site data for your domain. New visitors, and anyone opening your site in a private window, are not affected because they have no saved copy.

Two related details:

  • Closing and reopening the statement, or reloading the page, does not refresh it. The widget reads the saved copy each time the statement is opened.

  • Changing the widget's language does not refresh it either. Your custom statement is a single block of text and is not translated; only the widget's built-in fallback statement (shown when no custom statement is available) changes with the language.

Realistic Timing at a Glance

Where the visitor is looking

When they see your change

Dashboard Preview

Immediately

A visitor who has never opened your statement on this site

As soon as our servers' copy refreshes: between immediately and 60 minutes

A visitor who opened it before your change

Not until that browser's site data for your domain is cleared

You, in a fresh private/incognito window

Same as a brand-new visitor: up to 60 minutes

How to Check Your Change Yourself

Do these in order. Each step removes one copy.

Step 1: Confirm the save. Open the Accessibility Statement page in the dashboard and click Preview. If the preview is wrong, the save did not happen; fix and save again.

Step 2: Allow for the server copy. Nothing you can do from a browser shortens the 60-minute window. If you saved less than an hour ago and a busy site keeps fetching the statement, wait it out before assuming a problem.

Step 3: Drop your own browser copy. Pick one:

  • Private/incognito window. Starts with empty site storage, so the widget must fetch the statement fresh. This is the quickest test.

  • Add ?aacx-reset to your site's address (for example https://www.example.com/?aacx-reset) and load the page. The widget clears every piece of its own stored data for that site, including the saved statement, and reloads clean. This only affects the browser you do it in.

  • Clear site data for your domain in your browser's settings or developer tools. Same effect as above, but also clears anything else the site stored.

Then open the widget and click Statement. If the server copy has refreshed, you will now see the new text.

📷 Widget footer with the Statement button, and the statement viewer open

Step 4: Rule out a different statement being served. If the statement viewer shows generic text (a default "Our Commitment / Standards / Accessibility Features" statement) rather than your custom wording, the widget did not receive a statement for that site and subdomain and fell back to its built-in default. Common causes are a site whose subscription is not active, or a subdomain (for example blog.example.com) that has no statement of its own. Check which subdomain you edited.

If You Use the WordPress Plugin

The plugin does not store or serve your statement. The statement is always fetched by the widget in the visitor's browser, so nothing in WordPress sits between your dashboard save and your visitors. The plugin's caches are about widget settings and reporting data, not statement text.

What the plugin's buttons actually do:

  • Save Settings (Widget Customizer). Saves your widget settings, clears the plugin's own 30-minute copy of those settings, and clears the widget's stored data in your admin browser (including your saved statement copy). It does not touch the server copy of the statement or any visitor's browser.

  • Having trouble viewing updates? → Clear All Caches. Clears the plugin's stored settings and reporting data, clears widget data in your admin browser, and asks our servers to refresh their copy of your site's licence and widget settings. This also does not clear the server copy of the statement; that still refreshes on its own within 60 minutes.

  • Verify Connection (Connection card). Re-checks your account link and clears the plugin's stored settings and summary data.

A page-caching plugin or CDN in front of your WordPress site does not affect the statement either, because the statement text is never part of your page HTML.

📷 WordPress Widget Customizer toolbar showing Save Settings and the "Having trouble viewing updates?" link

When to Contact Support

Email [email protected] or use the chat in your dashboard if:

  • It has been more than 60 minutes since you saved, a fresh private window still shows the old text, and the dashboard Preview shows the new text.

  • The widget shows the generic default statement instead of your custom one, and the site's subscription is active.

  • You need to get a corrected statement in front of returning visitors quickly. We can advise on the best option for your situation.

Include your site address, which subdomain you edited, and roughly when you saved. That lets us check the server copy directly.

Frequently Asked Questions

Q: I saved, waited an hour, and I still see the old version. Why?
A: Most often because you are testing in a browser that opened the statement before your change. That browser is reading its own saved copy. Try a private window or add ?aacx-reset to your site address (see Step 3 above).

Q: Can I clear the server copy myself?
A: Not at the moment. It refreshes on its own within 60 minutes of the last time a visitor fetched it.

Q: Will visitors who already read my old statement ever see the new one?
A: Only after their browser's site data for your domain is cleared. The widget does not currently expire its saved copy. For an urgent correction, contact support.

Q: Does clearing my WordPress page cache help?
A: No. The statement is not in your page HTML. Page caches, CDNs, and WordPress caching plugins have no effect on it.

Q: Does switching the widget language show a translated statement?
A: No. Your custom statement is shown as written. Only the widget's built-in fallback statement is translated.

Q: My site has several subdomains. Do I need to save each one?
A: Yes. Each subdomain has its own statement and its own server copy.

Related Articles

Need Help?

Still seeing the old statement?

  • Email: [email protected]

  • Live Chat: Available in your dashboard

  • Include your site URL, the subdomain you edited, and when you saved

Last Updated: September 2026

Related Articles
Did this answer your question?