Configuring BrowserStack Accessibility Testing to Scope Axe‑Core Injection to Selected Domains
0 reputation · 10 Mar 2023, 05:41 UTC
0 reputation · 10 Mar 2023, 05:41 UTC
The BrowserStack Accessibility Testing feature injects the axe‑core library into every page loaded during an Automate or Live session when the accessibility capability is set to true. While this provides broad coverage, teams often need to limit scanning to specific domains or URL patterns to reduce noise and avoid CSP conflicts.
The current capability set does not expose a built‑in option to whitelist or blacklist URLs, and the documentation does not clarify whether custom capabilities can achieve scoped injection without disabling the feature entirely. Moreover, the interaction with strict Content Security Policies remains unclear when injection is restricted to a subset of frames.
Can a custom capability be defined to restrict axe‑core injection to a whitelist of domains? If such a capability is unavailable, what alternative mechanisms exist to obtain domain‑specific accessibility reports? How does BrowserStack reconcile CSP restrictions when injection is limited to selected frames?
33275 reputation · 10 Mar 2023, 06:47 UTC
There is currently no custom capability in BrowserStack that allows you to define a domain whitelist or blacklist to restrict the automatic injection of the axe-core library. When the accessibility capability is set to true, the platform attempts to inject the engine into every page loaded during the session.
To avoid noise from third-party domains or to prevent CSP conflicts on non-target pages, you should move from automatic injection to manual execution. By disabling the global accessibility capability, you can control exactly when and where the audit runs.
false in your configuration to prevent the platform from forcing axe-core into every frame.// Example logic for scoped execution
const currentDomain = await driver.executeScript("return window.location.hostname;");
const allowedDomains = ['myapp.com', 'staging.myapp.com'];
if (allowedDomains.includes(currentDomain)) {
// Trigger the axe-core audit here
const results = await driver.executeScript("return axe.run();");
console.log(results);
}
BrowserStack's automatic injection often attempts to bypass certain restrictions, but strict Content-Security-Policy (CSP) headers—specifically script-src—can still block the injection of the axe-core library.
When injection is limited to selected frames via manual scripts, the following behaviors occur:
To verify that your scoping is working and CSPs are being respected:
axe object should be undefined.axe object is initialized.Refused to execute inline script errors, which indicate that the CSP is successfully blocking injection on restricted pages.Diagnostic Detail Needed: Are you utilizing the BrowserStack SDK or a standalone WebDriver implementation? The method for injecting the manual script differs slightly between the two.
Use comments to ask for clarification. Post a solution as an answer.
33,275 reputation · 10 Mar 2023, 16:43 UTC
When shifting to manual execution to avoid global injection, it is important to note that axe.run() only scans the current document context. If your target domain utilizes cross-origin iframes, these will be excluded from the audit by default due to browser security boundaries.
To include specific iframes in your scoped reports, you must explicitly switch the driver context to each frame before triggering the audit:
driver.switchTo().frame() to move into the target iframe.axe.run() script within that specific context.If manual injection still fails on specific domains, check the browser console for Content-Security-Policy violations. If script-src is strictly defined, you may need to coordinate with your DevOps team to temporarily allow the BrowserStack script source in the staging environment to enable accessibility testing.