How to Test Website Accessibility with BrowserStack

How do I test website accessibility with BrowserStack? Choose Website Scanner for scheduled scans of a site, Workflow Analyzer for pages and states in a user journey, and BrowserStack’s SDK when accessibility checks should run alongside existing functional browser tests. Use Assisted Tests and Screen Reader sessions for guided and assistive-technology checks. Then fix findings, retest, and manually evaluate keyboard behavior and assistive-technology usability. An automated report helps identify issues; it cannot prove that a site is accessible or conforms to WCAG by itself. W3C requires knowledgeable human evaluation.

BrowserStack also offers Accessibility DevTools for scanning source files locally or in CI. Source checks and browser checks cover different layers: source scanning examines selected files, while browser workflows inspect rendered pages and states. Neither replaces human evaluation. See BrowserStack’s accessibility testing overview.

1. Set the target and scope

Before configuring a scan, decide which pages, states, and user journeys matter. Include more than the homepage: test important tasks such as signing in, searching, completing a form, or checking out, including validation and error states where relevant.

Confirm the accessibility standard and level required by your policy, contract, or project. BrowserStack’s documented automated-test default is WCAG 2.1 AA. Its configuration lists WCAG 2.0, 2.1, and 2.2 levels, as well as RGAA. W3C advises using WCAG 2.2 to maximize future applicability, but a project may have a different governing requirement. WCAG 2.2 adds criteria including Focus Not Obscured, Focus Appearance, Target Size, and Accessible Authentication. See the WCAG 2.2 Recommendation and BrowserStack configuration options.

Question	Record before testing
What is in scope?	Pages, workflows, roles, and meaningful page states
What is the target?	Standard, version, and conformance level required by the project
Where will it run?	Local source scan, CI, BrowserStack browser session, or scheduled site scan
How will results be interpreted?	Included issue classes, exclusions, browser and framework, and manual checks planned

2. Choose the BrowserStack testing mode

Mode	Use it for	Key point
Website Scanner	One-time or recurring scans of a website	Can use a sitemap URL; BrowserStack documents setup for internally hosted sites.
Workflow Analyzer	Several pages or states in a user flow	Detects static issues such as missing alternative text and insufficient color contrast across workflow states.
Automated tests (SDK)	Checks integrated with an existing functional browser suite	The SDK runs Workflow Analyzer as the test script traverses rendered pages and states. Automated tests are available on paid plans.
Assisted Tests	Guided evaluation of a page or component	Semi-automatic: BrowserStack examines the page and asks you to confirm observations.
Screen Reader	Sessions with supported assistive technologies on real devices	BrowserStack documents VoiceOver on Mac, NVDA on Windows, and TalkBack on Android. Check current device availability before planning a session.
Accessibility DevTools	Source-code checks in an IDE, locally, or in CI	The CLI can scan selected source files and produce reports. It is a different layer from rendered-page testing.

Use the product overview to choose a mode, and check the automated testing documentation for your framework and browser combination. Browser and framework support varies: Chrome is broadly listed, while Safari, Edge, and Chrome on Android support depends on the framework.

3. Configure automated checks

For SDK-based checks, set the standard and version, then decide which kinds of findings to include. BrowserStack’s configuration options include best-practice issues, issues that need review, experimental and advanced rules, and test-case inclusion or exclusion tags. You can also configure automatic scans after DOM changes. Choose this behavior deliberately: if a workflow changes the DOM repeatedly, automatic rescanning can affect runtime and the number of findings.

Set the standard and level to match the project requirement.
Decide whether to include best-practice, review-needed, experimental, or advanced issue classes.
Use test-case tags to control which cases participate, if needed.
Decide whether DOM changes should trigger scans automatically.
Document the configuration alongside the test suite so later reports can be interpreted consistently.

Use the current configuration reference for exact SDK syntax and option names; they depend on the integration. Do not copy settings from an old report without checking whether its target and issue filters match the present test.

4. Add checks to an existing browser workflow

If functional tests already run on BrowserStack Automate, integrate the BrowserStack accessibility SDK so it evaluates pages as the script moves through the workflow. For example, a functional test can open a route, interact with a form, submit it, and reach a confirmation state; the accessibility run can then inspect the rendered states traversed by that test.

The integration is framework-specific, so there is no single correct universal code snippet. Follow the official SDK integration instructions for your framework, then verify that:

The test reaches the intended page states before the scan runs.
The configured WCAG or RGAA target matches the project.
Per-test and consolidated reports are available in the Accessibility Dashboard.
Custom assertions, if used, reflect issues the team intends to fail builds on.

The SDK’s workflow checks run with functional tests and produce per-test and consolidated reporting. Validate the browser and framework pairing against BrowserStack’s current support matrix because support is not identical across combinations.

5. Scan source files with Accessibility DevTools

Use Accessibility DevTools when you want to catch source-level issues locally or in CI. Its CLI can scan all matched files or focus on changed lines in a Git repository. It supports include and exclude patterns and can generate HTML, JSON, or SonarQube Generic Issue output. HTML reports include issue and location detail.

Install and invoke the CLI using the current BrowserStack CLI instructions; installation and command flags can change, so use that page as the source of truth for executable commands. Choose a full scan for broad coverage or changed-line scanning for a narrower pull-request check. Treat a source scan as an early feedback layer, then check rendered pages and user workflows in a browser.

6. Review findings, fix, and retest

Use reports to locate findings and understand which test, page, or state produced them. Triage each finding against the affected interaction and content, fix the underlying issue, and rerun the relevant workflow. Avoid treating a raw issue count or score as proof of conformance: the report reflects the rules and states that were tested, not every way a person may use the site.

Confirm the finding is reproducible in the reported state.
Identify whether the issue originates in shared components or page-specific markup.
Fix the cause, then rerun the affected test and nearby workflows.
Check keyboard operation and focus behavior manually.
Use supported assistive technologies to evaluate whether content and controls make sense in context.

7. Complete human evaluation

Automated checks can find many detectable problems, but cannot assess every accessibility requirement or determine conformance on their own. W3C’s guidance is explicit: knowledgeable human evaluation is required. Test with keyboard-only navigation and appropriate assistive technologies, and include realistic content and dynamic states. BrowserStack’s Screen Reader and Assisted Tests can support this work, but use them as part of an evaluation rather than a substitute for informed judgment.

When reporting results, state the standard and level, pages and states covered, browser and framework combination, automated and manual methods, unresolved issues, and evaluation date. W3C describes WCAG-EM as a conformance evaluation method; its report tool helps create documentation but does not perform the checks. See W3C evaluation guidance.

Or skip the browser setup

For a visual screenshot of a page while you evaluate it, ScreenshotNeo is a website screenshot API and MCP server for developers. It does not replace accessibility testing, issue reports, keyboard checks, or assistive-technology evaluation. Its API returns a PNG, JPEG, WebP, or PDF from one GET request. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie and consent banners, newsletter popups, and chat widgets are removed before capture; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers indicate the page verdict and billing status.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
1,000 screenshots per month are free with no card; paid plans start at $5 for 3,000 screenshots.

Troubleshooting

Symptom	Likely cause	What to do
No accessibility results for a workflow	The integration is not enabled for the test, or the test did not traverse the expected pages.	Check the SDK configuration and confirm the functional test reaches the target states. Review the run’s per-test output.
A browser or framework combination is unavailable	Support varies by framework; Safari, Edge, and Android Chrome are not listed for every combination.	Check the current support matrix in the automated tests documentation and select a supported pairing.
Findings differ between runs	Different page states, DOM timing, scan triggers, issue filters, or content can change what is evaluated.	Stabilize the workflow and record target, filters, and DOM-change scan behavior. Compare equivalent states and settings.
A source scan misses a browser issue	Source scanning does not evaluate all rendered behavior or runtime states.	Add rendered-page or workflow checks, then manually evaluate keyboard and assistive-technology behavior.
A finding does not appear in a report	Its rule class may be excluded, the test case may be filtered out, or the relevant state may not have been scanned.	Review issue-type settings, inclusion and exclusion tags, and workflow coverage before concluding it is absent.
A clean report is being treated as compliance proof	Automated scans cannot make a complete conformance determination.	Report the tested scope and methods, and complete knowledgeable human evaluation under the project’s target.

Performance, reliability, and cost considerations

Runtime: accessibility analysis runs alongside the browser workflow. DOM-change rescans may add work on pages that update frequently; configure scan behavior around the application and suite.
Coverage: scheduled site scans, workflow scans, source checks, and human testing answer different questions. Combining them gives a more useful picture than relying on one report.
Reliability: reports are meaningful only when the tested browser, framework, state, standard, and filters are known. Keep these settings stable and record them with results.
Cost: BrowserStack documents automated tests as paid-plan only. The research sources do not establish current prices, so check BrowserStack’s current plan details before budgeting.

FAQ

Can automated accessibility testing prove WCAG compliance?

No. Automated findings can guide remediation, but W3C says knowledgeable human evaluation is needed to determine accessibility.

Should every project use WCAG 2.2?

W3C advises using WCAG 2.2 for future applicability, but follow the standard and version required by your policy, contract, or other governing requirement.

Can I use Accessibility DevTools instead of browser workflow tests?

Use it as a source-code check, not a replacement. It does not cover all rendered page states or real user interaction.

Does BrowserStack’s SDK work with every browser and framework?

No. Support depends on the combination. Consult the current BrowserStack matrix before selecting a test environment.