Troubleshooting

The widget doesn’t show

Open your site in a private window, so no extension or old cache gets in the way, and check these in order:

1. Is the script on the page? View the page source and search for autoload.js. If it isn’t there, the tag was never added, or a theme update or page builder removed it. Copy it again from the dashboard’s Installation page.
2. Does the domain ID belong to this site? Compare the domainId in the tag with the one on this site’s Installation page.
3. Did the requests succeed? In developer tools, open Network and filter for accessora. See what a working install loads.
4. Any errors in the console? Look for lines that start with Accessora: and for Content Security Policy errors.
5. Is the launcher hidden on purpose? If Hide Floating Icon is on under Custom Triggers, the widget only opens from your own button or the Open Accessora skip link.
6. Is something on top of it? A chat bubble or cookie banner in the same corner can cover the launcher. Move it in Settings.

Verification fails

Verify installation loads your site’s address in a headless browser, waits up to 30 seconds and looks for the script with this site’s domain ID. When it fails, it is usually one of these:

• Script not found. The tag isn’t on the page, or was removed by a page builder or theme update. Copy it again from the Installation page.
• Domain ID mismatch. The tag was copied from another site in your account. Each site has its own ID in the domainId parameter.
• The page didn’t load in time. Password-protected pages, bot challenges such as a Cloudflare check, and very slow home pages all stop the check before it finds anything.
• A cached page. Full-page caching on a CDN, a static export or a reverse proxy can serve an old copy without the tag. Purge the cache and verify again.

More on each message in verify your install.

Caching and optimizer plugins

Speed plugins often rewrite scripts, and two of their features stop the widget:

• Delaying JavaScript until the visitor interacts. WP Rocket’s Delay JavaScript execution, and similar options in LiteSpeed Cache, SiteGround Speed Optimizer and others, hold the widget back until someone moves the mouse or scrolls. Keyboard and screen reader users may never see it.
• Combining, minifying or moving scripts. This can strip the ?domainId= query string or change the script’s address, and then the widget can’t find your settings.

Fix it by excluding the Accessora script. Add cdn.accessora.io or autoload.js to the plugin’s exclusion list for delayed, combined and minified JavaScript. Then purge the cache.

Cloudflare Rocket Loader defers scripts in a similar way. Tell it to skip the widget by adding data-cfasync="false" to the tag:

<script data-cfasync="false" async src="https://cdn.accessora.io/embeds/js/latest/autoload.js?domainId=YOUR_DOMAIN_ID"></script>

Content Security Policy

If your site sends a Content-Security-Policy header, the browser blocks anything the policy doesn’t list, and the widget fails without a visible error. Add these sources to the directives you already have:

A complete example, with your own sources in place of 'self' where needed:

Content-Security-Policy:
  script-src 'self' https://cdn.accessora.io;
  connect-src 'self' https://dash.accessora.io;
  style-src 'self' 'unsafe-inline' https://fonts.bunny.net;
  font-src 'self' https://fonts.bunny.net https://cdn.accessora.io;
  img-src 'self' https://cdn.accessora.io

To test a policy without breaking the live site, send it as Content-Security-Policy-Report-Only first and watch the console.

Single-page apps

In React, Vue, Next.js, Nuxt and similar apps, load the script once in the layout that wraps every route, not inside a page component. The widget then stays mounted while visitors move between routes:

• Page-wide adjustments such as High Contrast and Stop Animations stay on, because the choices are kept in the browser.
• Font Size and Line Height apply to the text on the page when they’re switched on. New content from a route change may need a reload to pick them up.
• Skip links, and on Enterprise the automated fixes, watch the page and update when a new route renders.

If your framework replaces the whole <body> on navigation, as Turbo Drive and some page transition libraries do, the widget can disappear after the first click. Contact us with the framework you use and we’ll help you set it up.

Blocked by a network or ad blocker

Some DNS filters, including security filtering that some internet and mobile providers switch on for their customers, block cdn.accessora.io. So do some ad-blocking and privacy extensions. For those visitors the widget doesn’t load at all, while everyone else sees it. It looks like an outage but it isn’t.

To check whether a visitor’s network is the cause:

• Ask them to open the site on mobile data or another network. If the widget appears there, the first network blocks it.
• In developer tools, a request to cdn.accessora.io that fails with ERR_NAME_NOT_RESOLVED points to DNS. ERR_BLOCKED_BY_CLIENT points to an extension.
• Look up the host from their network:

nslookup cdn.accessora.io

No address at all, or a different address than you get on another network, means the network’s DNS filters the host. The visitor, or whoever runs the network, can ask the provider to allow cdn.accessora.io.

Shopify store shows no widget

• Check the Accessora app embed is switched on in the theme you have published, not a draft copy, and that you saved the theme.
• Open the storefront in a private window, so an old cached copy doesn’t fool you.

See install the Shopify app.

Usage limit reached

• Page views. They have no limit, so the widget keeps working for visitors.
• Audits and AI alt text. New scans and new descriptions stop until the first of next month.

You can move to a bigger plan at any time from Billing. See plans and limits.

Settings don’t show on the site

Settings are cached for up to a minute, on our side and in the visitor’s browser. Wait a minute, then reload the page.

Automated fixes don’t apply

• Automated fixes need the Enterprise plan, active or in trial.
• Check Enable Automated Fixes is on in Settings.
• Run window.__accessoraFixesReady in the browser console. If it is undefined, the fixes didn’t start. See check what was fixed.