How to check service worker support in a browser

Before an accessibility audit, you may need to know whether the browser can run a site’s service worker. This matters if the site depends on one for offline use, saved app files, or updates. A browser can support service workers even when the site has not registered one, so checking browser support is only the first part of the test.

Use the Browser Info report to check the browser and its supported features. Then check the audit site itself, because its security and setup affect whether a service worker can run.

Check service worker support

1. Open Browser Info and review the browser details and supported features. Look for a service worker entry if the report lists one.
2. Note the browser name, version, and engine. If you are auditing on a particular device or browser, run the check there rather than relying on results from another computer.
3. Open the site you plan to audit using its regular address. Service workers generally require a secure context, which means HTTPS. Local development addresses such as localhost are an exception.
4. If you can use browser developer tools, check the site’s service worker status. In Chrome or Edge, open Developer tools and choose Application › Service Workers. Look for a registered worker and whether it controls the page.
5. For a simple API check, open the developer console on the site and enter 'serviceWorker' in navigator. A result of true means the API is exposed in that page’s context. It does not prove that the site has registered or activated a worker.

Keep the site address, browser version, and result with your audit notes. If another auditor gets a different result, comparing those details can help explain why.

What the result means

The browser reports service worker support

The browser exposes the feature, so it can run service worker code when the site and browser context allow it. This alone does not show that a specific site uses a worker, that the worker is active, or that offline behavior works.

The feature is missing from the report

Some reports may not list every browser feature or may use a different label. Check the browser version and try the console check on the HTTPS site. If the result is false, try an up-to-date browser that supports the API before concluding that the site is at fault.

The API is available, but no worker controls the page

The browser can use service workers, but the site may not have registered one, or the worker may not have finished installing and activating. A first visit may not be controlled immediately. Reload the page and check again, or ask the site team whether a worker is expected on that address.

A worker is registered, but the page looks out of date

A registered worker can serve cached files, including an older version of a page or its scripts. Record what you see before clearing anything. If the site has an update or offline workflow, test that workflow separately from the fresh-page audit.

How to fix a missing or unexpected result

1. Check that the site uses HTTPS. A service worker usually cannot run on an ordinary HTTP site. Open the secure version of the address, or ask the site owner to enable HTTPS. For local development, localhost is treated as a secure context.
2. Use a regular browser window. Private browsing and managed browser policies can limit storage or clear it when the session ends. Repeat the check in a normal window, especially if the audit requires persistent offline behavior.
3. Update the browser. On Windows 11, check Settings › Windows Update › Check for updates. On macOS, check System Settings › General › Software Update. Chrome and Edge can also update through their own Help › About menu; Safari updates with macOS.
4. Check the site’s registration and activation. If the API is available but no worker appears in developer tools, the site may not register one on that page, or the registration may have failed. Share the page address and browser version with the site’s developer or support team.
5. Clear site data only after recording the current state. A stale worker or cache can sometimes make a site load older files. Clearing site data can sign you out and remove saved settings, so note the current result first and follow the site owner’s instructions if the audit needs a repeatable cache state.

There is no general Windows 11 or macOS privacy switch for service workers. The important conditions are the browser, the site’s secure context, its registration code, and any browser or workplace policies that affect site storage.

Keep the accessibility audit separate from the support check

Service worker support is not an accessibility score. It does not tell you whether the page works with a keyboard or screen reader, whether controls have useful names, or whether text has enough contrast. Check those accessibility requirements directly.

Still, a service worker can affect which version of the page you audit. If offline access or cached updates are part of the product, include those states in your test plan. Record whether you tested a first visit, a repeat visit, an update, or an offline page so that results can be repeated consistently.