An accessibility widget can fail to appear even when the current service connection is valid. In one WordPress support case, AudioEye was connected and verified through the site plugin and the active AudioEye account, but the accessibility icon was not showing on the frontend.
The confirmed cause was not a failed account connection. The site still contained an older AudioEye embed from a previous provider inside the Beaver Builder Footer Menu. That stale code created a duplicate legacy implementation alongside the new AudioEye setup. Once the old footer code was removed, the issue was reported as fixed.
Issue background
A WordPress site had recently transitioned its AudioEye service from a previous provider to a new account with updated credentials.
The new AudioEye connection appeared healthy:
- The WordPress integration was connected.
- The site was verified in the active AudioEye account.
- AudioEye scans were completing successfully.
Despite that, the expected accessibility icon was not appearing in the corner of the site.
The team also knew that the site had historically used a separate AudioEye embed, so duplicate implementation was a possibility.
Diagnosis
Several possible causes were considered, including caching, JavaScript deferral, and recent plugin updates. WP Rocket had been updated recently, and performance plugins can sometimes delay third-party scripts.
However, the source task does not document WP Rocket or JavaScript optimization as the confirmed cause.
The decisive finding was older AudioEye code still embedded in the site’s Beaver Builder Footer Menu.
That code belonged to the prior AudioEye configuration and loaded its own AudioEye scripts and widget markup in addition to the current plugin-based setup.
This created redundant AudioEye initialization on the same page. The site had effectively been transitioned to a new account while still carrying the old provider’s frontend embed.
Resolution steps
The documented resolution was:
- Confirm that the current AudioEye connection was valid. The plugin connection, account verification, and scan activity all indicated that the new setup was active.
- Inspect the site for legacy AudioEye code. The team reviewed the Beaver Builder footer area rather than assuming the active plugin was the only implementation.
- Locate the outdated embed. Old AudioEye JavaScript and widget markup from the previous provider were found inside the Beaver Builder Footer Menu.
- Remove the stale footer code. The legacy AudioEye embed was deleted so the site would rely on the current AudioEye integration only.
- Avoid making unrelated changes without evidence. Although caching and JavaScript deferral were considered during troubleshooting, the source thread does not document any WP Rocket configuration change as part of the completed fix.
- Confirm the issue was resolved. After the old footer embed was removed, the project manager reported the issue fixed and notified the client.
The original task contained account-specific AudioEye script hashes and site identifiers. Those values are intentionally omitted here because they are not needed to reproduce the troubleshooting process.
Final outcome
The missing AudioEye accessibility icon issue was resolved by removing outdated AudioEye code from the Beaver Builder Footer Menu.
The current AudioEye account and WordPress integration were already connected and verified. The problem was the leftover legacy embed from the previous provider, which created a duplicate implementation on the frontend.
The broader lesson is that third-party service migrations often leave old scripts behind in theme builders, footer modules, code snippets, or tag managers. When a replacement integration appears connected but the frontend widget behaves incorrectly, audit the site for older embeds before changing cache or performance settings.
If AudioEye or another accessibility widget is connected but not rendering correctly on your WordPress site, contact Freshy. Our WordPress team can trace duplicate embeds, legacy scripts, and builder-level integrations to restore the current accessibility setup cleanly.
