Quicksloth

How to remove UserWay from WordPress completely

Last updated: 4 November 2026

Deactivating "Accessibility by UserWay" hides the widget, but it keeps your UserWay account ID in the database, and the widget comes back as soon as the plugin is activated again. To remove it for good, delete the plugin from the Plugins screen, remove any UserWay code that was added by hand, clear your caches, then check that no page loads anything from userway.org.

People remove UserWay for different reasons: page weight, privacy reviews, a move to another tool or no toolbar at all. This guide works for all of them. We make a free accessibility toolbar for WordPress, so weigh what we say with that in mind; the WordPress steps below were tested on WordPress 7.1.4 with UserWay's plugin version 2.6.6 on 4 November 2026.

The short version

  1. In Plugins → Installed Plugins, click Deactivate under Accessibility by UserWay, then Delete, and confirm.
  2. Look for UserWay code added outside the plugin: theme files, a code-snippet plugin, a Custom HTML block or Google Tag Manager.
  3. Clear your caching plugin, your host's cache and your CDN.
  4. Open your site in a private window and check that nothing from userway.org loads.
  5. If you pay for UserWay, cancel the subscription in your UserWay dashboard; deleting the plugin does not cancel it.

Where UserWay can be on your site

UserWay's widget is a script, widget.js, loaded from cdn.userway.org. On a WordPress site it usually gets there in one of these ways:

More than one can be true: a site may still carry hand-added code from before the plugin was installed, which is why the last check matters.

Delete the plugin, don't just deactivate it

  1. In your dashboard, go to Plugins → Installed Plugins.
  2. Under Accessibility by UserWay, click Deactivate.
  3. Click Delete in the same row. WordPress asks "Are you sure you want to delete Accessibility by UserWay and its data?": click OK.

Why the second click matters: when the plugin is activated it creates its own database table, wp_userway (with your site's table prefix), and stores the UserWay account ID there. Deactivating leaves that table in place. The plugin's uninstall routine, which WordPress runs when you click Delete, drops it. UserWay's help center gives the same warning for a different problem: "Simply deactivating and reactivating the plugin will not resolve this issue. The previous installation information may remain stored in the WordPress database."

One small entry stays behind: the option usw_userway_activation_notice, which the plugin uses for its admin notice. It holds the value 1 and does nothing once the plugin is gone. If you want a perfectly clean database and you use WP-CLI:

wp option delete usw_userway_activation_notice

If you use WP-CLI to remove plugins: wp plugin delete removes the files only and skips the uninstall routine, so the table stays. Use uninstall instead:

wp plugin uninstall userway-accessibility-widget --deactivate

If the plugin's files are already gone and the table is still there, this drops it, whatever your table prefix is:

wp eval 'global $wpdb; $wpdb->query( "DROP TABLE IF EXISTS {$wpdb->prefix}userway" );'

Take a database backup first, as with any change you make to the database directly. Without WP-CLI, your host's database tool (often phpMyAdmin) can do the same: look for the table whose name ends in userway.

What we saw in a test site

We installed version 2.6.6 on a fresh WordPress 7.1.4 site, stored a made-up account ID the way the settings page does after sign-up, and went through each step with WP-CLI. Outgoing requests from the server were logged and blocked, so nothing reached UserWay.

StepWidget script in the pagewp_userway tableLeftover option
Activated, account linkedYes, from cdn.userway.orgYes, with the account IDYes
DeactivatedNoYes, with the account IDYes
Activated againYes, straight awayYesYes
Files removed with wp plugin deleteNoYes, with the account IDYes
Installed again after thatYes (old account ID still there)YesYes
Uninstalled (same as Delete on the Plugins screen)NoRemovedYes, until deleted by hand

Two more things showed up in the code. While the plugin is active and has no account stored, each front-end page view makes the server ask api.userway.org for an account linked to the site's host name.

Remove code that was added by hand

Search for the word userway wherever code can live. In the dashboard:

If you have WP-CLI and SSH access, two commands, run from your WordPress folder, find most of it at once. We tested them with the UserWay code placed in WPCode, a child theme and a post: the first found the WPCode setting and the post, the second found the theme file.

wp db search userway --all-tables-with-prefix --stats
grep -ril userway wp-content/themes wp-content/plugins wp-content/mu-plugins

After you have removed everything, wp db search may still show one match in the option recently_activated. That is WordPress's own list of recently deactivated plugins, not UserWay code; WordPress drops entries older than a week from it.

Clear every cache

A cached page can keep serving the old HTML, with the UserWay script in it, after you removed it. Clear, in this order: your caching plugin, your host's cache, if it has one, and your CDN, such as Cloudflare. UserWay's own guide makes the same point when the widget is installed: clear "all website caches, including any WordPress caching plugins, CDN caches, and server-level caches".

Its troubleshooting tip works in reverse too: open an address that does not exist on your site, such as https://example.com/asdf. As UserWay notes, "Most 404 pages are not cached": if the widget is gone there but still shows on your home page, a cache is still holding the old page.

Check that nothing loads any more

In the browser. Open your site in a private window and open the developer tools (F12, or Cmd+Option+I on a Mac). In the Network tab, tick Disable cache, reload the page and type userway in the Filter box. The list should stay empty. Repeat on a page of each type: home, a post, a shop or checkout page.

From a terminal. These commands fetch a page and its 404 version. Replace example.com with your domain.

curl -s https://example.com/ | grep -i -c userway
curl -s https://example.com/asdf | grep -i -c userway

Both should print 0. If the first command still counts matches but the 404 page does not, go back to the caches.

Visitors' browsers. UserWay says the widget stores each visitor's settings in that visitor's own browser storage, not in cookies, until they clear it. That data is on their devices, so there is nothing for you to delete on your server, and no UserWay script is left to read it.

Cancel the plan and delete the site in UserWay

Deleting the plugin does not touch your UserWay account. If you no longer use it, two steps in the UserWay dashboard at manage.userway.org, as UserWay's help center describes them:

  1. Cancel a paid plan. Click your profile icon at the top right, choose Subscriptions, open the subscription, click Manage, then Cancel Subscription and Proceed with Cancellation, pick a reason and confirm with Cancel Subscription. The plan stays active until the end of the current billing period (UserWay's guide).
  2. Delete the site. In My Sites, open your domain, go to the Settings tab and click Delete Site at the bottom. UserWay notes that "Sites with an active subscription cannot be deleted", so cancel first and wait for the plan to expire; a deleted site moves to the Deleted tab and can be restored (UserWay's guide).

Turning the widget off in the dashboard is not the same thing: UserWay says it "does not remove the installation code from your website" (UserWay's guide). We found no help article on closing a whole UserWay account; for that, ask UserWay's support.

If you still want a toolbar

You may not need one. Browsers and operating systems already let people enlarge text, change colors and stop animations on every website; our guide on what a widget does and does not do explains when a toolbar helps and when it does not.

If you want to keep one, ours is one of the options: Quicksloth Accessibility Toolbar is free in the WordPress.org Plugin Directory, needs no account, serves its files from your own site, sends no requests to other servers and sets no cookies. Deleting it removes the settings it stored. Our UserWay alternative page compares the two side by side, and the live demo lets you try it first.

An accessibility toolbar helps some visitors; it does not make a website conform to WCAG or to the law. Fix your content and code first.

Questions and answers

Is deactivating UserWay enough?
It stops the widget from loading, as long as no other copy of the code is on the site. But the account ID stays in the database, and the widget returns if anyone activates the plugin again. Delete the plugin if you are done with it.
Will removing UserWay break my site?
The plugin stores only its own table and one option; it does not change your posts or theme. What goes away is the widget, and anything it did in the browser: if you added image descriptions or other fixes in UserWay's dashboard, they do not live in WordPress, so add them to your content directly.
I reinstalled the plugin and it remembered my old account. Why?
Most likely its database table survived an earlier removal that skipped the uninstall routine, for example wp plugin delete or deleting the plugin folder by FTP. Uninstall it from the Plugins screen, or drop the table with the command above.
Does UserWay leave cookies on my visitors' devices?
UserWay says its widget keeps accessibility settings in browser storage, not in persistent cookies. In the WordPress admin, the plugin sets one cookie for the administrator who dismisses its notice, usw_userway_activation_notice_dismissed.

Sources

All read on 4 November 2026.

Written with AI tools and checked by Quicksloth: WordPress steps tested on a throwaway WordPress 7.1.4 site with UserWay's plugin 2.6.6 and WPCode 2.4.1, quotes compared with the linked pages. If something has changed, tell us at support@quicksloth.dev and we will correct this page.